Perhaps replacing "technical infrastructure" with "addresses assigned to equipment and/or interfaces physically present within the ARIN region".
Owen On Oct 7, 2013, at 8:37 AM, John Curran <[email protected]> wrote: > On Oct 6, 2013, at 3:22 PM, William Herrin <[email protected]> wrote: > >> There is a subtlety here that is escaping me. If the addresses are >> assigned to hosted infrastructure within the region then how are they >> not used within the region? > > Bill - > > Apologies in advance for length - the community is entitled to a complete > understanding of how we administer number resources, and that appears to > take more words than I expected at first.. > > Technical infrastructure can be used to justify addresses (for example, > network routers, POP equipment, concentrators, management systems, IT > systems, data center servers, etc.) We're very experienced with this, > and often ask for equipment lists, invoices, etc. to confirm existence > of the asserted equipment. > > When technical infrastructure grows, more IP addresses are needed for > assignment to the technical infrastructure. Technical infrastructure > exists in a region based on the location of the physical devices. > > Customers growth can also justify addresses (e.g. you assign addresses to > an single customer, or customer growth requires that a certain dynamic pool > assigned to customers be expanded) We are also quite experienced with the > verification of customers, including obtaining customer lists, contact info, > etc. > > When the number of customers served grows, more IP addresses are needed to > assign to the new customers, or to assign to the dynamic pools for those > customers. Customers exist in a region, based on their actual location of > each customer. > > For example, if someone needs more addresses because they are adding > new VPN concentrators (i.e. more actual equipment itself), then that is > indeed technical infrastructure need based on where the equipment will > be installed. i.e. if you buy stacks of new VPN concentrators and have > no addresses to connect them to your infrastructure, it's a simple matter > to request (per policy) additional addresses needed. We do this all of > the time with the infrastructure side of DSLAMS, cable head-ends, wifi > nodes, etc. > > If someone needs additional addresses for their _customers_ (including > to expand a dynamically assigned pool), then we verify the customer > growth as noted earlier, including the location of the customers. > > Requesters have to show that they have additional equipment or additional > customers to obtain addition addresses. Both equipment and customers are > associated with real-world addresses, and hence are within some region of > the registry system. > >> What aspect of the draft policy would change that evaluation? ... > > The draft policy 2013-6 reads as follows: > > "In addition to meeting all other applicable policy requirements, > a plurality of new resources requested from ARIN must be justified > by technical infrastructure or customers located within the ARIN > service region, and any located outside the region must be > interconnected to the ARIN service region." > > The requesters who were previously discussed (i.e. "the 52" who have received > allocations since mid-year), often have some existing infrastructure, are not > adding anything more, and do not need more addresses due to their _technical > infrastructure_ growth. > > They do have remarkable customer growth, and hence need additional addresses. > > Under the policy change proposed by 2013-6, we would only consider customers > within the ARIN service region for this purpose, and would provide an > allocation > which they could justify based on that in-region customer demand. The > proposed > policy change makes clear that customers must be in-region to be considered. > (The present policy does not have such a constraint, hence the approval of > recent requests where the vast majority of customers are known to be outside > the ARIN region.) > > We don't consider virtual "technical infrastructure" for assessing the need > for addresses, even though service providers may use such when adding > customers. > The additional customers driving such virtual growth are readily verifiable. > The alternative would be to consider virtual equipment (e.g. VM's) as actual > technical infrastructure and that would effectively open the justification of > unlimited resources by any party without any actual equipment or customer > growth. > > If the desire was to simply clarify existing policy (without actually > changing > the current practice), it could be accomplished by dropping the "in region" > requirement for customers as follows: "must be justified by technical > infrastructure within the ARIN or by customers located anywhere as long as > the addresses are managed and interconnected in the ARIN service region." > (Note that such a change would make rather clear that nearly any > heavily-utilized > customer-driven IP address pool interconnected in the ARIN region can qualify > for additional resources, which may or may not be a desirable outcome > depending > on one's individual perspective.) > > I hope this helps in clarifying what ARIN-2013-6 would be change to the > existing policy, as it would make clear that customer growth in-region > would be necessary to justify requests, whereas presently we have some > folks requesting resources using nominal equipment within the region and > backed by extensive customer growth external to the region. > > Please do not hesitate to ask if you have any further questions - it is > indeed very important that folks understand how we implement the policy > in order to fully consider any proposed policy changes, so thank you for > your diligence on this topic. > > /John > > John Curran > President and CEO > ARIN > _______________________________________________ > 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. _______________________________________________ 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.
