[arin-ppml] ARIN-prop-178 Regional Use of Resources

Fri Jul 13 18:27:03 EDT 2012

 	Hello All ,  I for one really disagree with such verbage .
 	Due to ...

 	1 )	UnEnforcability .
 	2 )	Limit'ting resource usage .

 	I am quite sure others can & will provide other & more concise reasoning 
than mine .

 		Twyl ,  JimL

On Fri, 13 Jul 2012, ARIN wrote:

> ARIN-prop-178 Regional Use of Resources
>
> Resending a better formatted version.
>
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
>
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
>
> The AC invites everyone to comment on the proposal on the PPML,
> particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> ARIN-prop-178 Regional Use of Resources
>
> Proposal Originator: David Farmer
>
> Date: 13 July 2012
>
> Proposal type: New
>
> Policy term: Permanent
>
> Policy statement:
>
> Add the following as a new policy section, substituting the actual
> section number selected for X:
>
> X. Regional Use of Resources
>
> All requests for number resources must meet the following criteria
> regarding regional use of resources, in addition to any resource
> specific criteria.
>
> X.1 Use in ARIN Region
>
> All organizations are entitled to receive resources from ARIN for use
> inside the ARIN service region and may use an incidental total of its
> ARIN registered resources outside the region. One eighth (or 12.5%) of
> said resources by each type, but no less than a /24 for IPv4, a /48 for
> IPv6, and one ASN, are considered incidental for this purpose.
>
> X.2. Headquartered in the ARIN Region
>
> Only organizations headquartered in the ARIN service region are entitled
> to receive resources from ARIN for use outside the region, in excess of
> the incidental use defined above, to operate a connected multi-region
> network, provided they have not received any resources for the same
> infrastructure from another RIR.
>
> If such an organization has received any resources from another RIR, an
> operational justification is required to clarify how the resources from
> ARIN will not duplicate any resources from another RIR. However, it is
> never justified to receive resources from ARIN and another RIR in order
> to evade another RIR'?s policies, or solely based on the availability of
> resources from another RIR, or the lack thereof.
>
> X.3. Preceding Use of Resources
>
> All ARIN registered resources received and used outside the ARIN region
> prior to implementation of this policy, may continue to be used outside
> the ARIN region. However, such resources are counted toward an
> organization'?s incidental use outside the region, unless the resources
> qualify under X.2.
>
> X.4. Critical Infrastructure Exempt
>
> All resources received under any RIR's critical infrastructure policy or
> equivalent, are exempt from this policy, due to their small resource
> impact and importance to Internet stability and operations.
>
> X.5. Use in Multiple Locations
>
> Any resource used simultaneously in multiple locations, like an anycast
> prefix or ASN, is considered used inside the region, provided at least
> one of the locations is inside the region, regardless of how many other
> locations outside the region its also used.
>
> X.6. Service Region and Headquarters when received
>
> The service region in effect and headquarters location of an
> organization when resources were originally received applies to any
> utilization review of those resources.
>
> Rationale:
>
> The primary purpose of this policy is to determine who is entitled to
> request new resources, either by direct assignment, allocation, or
> transfer, from ARIN and for use in what service regions. The following
> summarizes the essence of it:
>
> ?* Anyone (either from inside or outside the region) may receive
> resources for use (fulfilling operational need) inside the ARIN region
> and use a small amount outside the region.
>
> ?* Anyone headquartered (primary center of business or administrative
> operations) inside the ARIN region may receive resources for use in a
> globally connected network, only if they have not received resources
> from another RIR for the same purpose. If they have received any
> resources from another RIR, they must explain how the ARIN resources
> requested are not intended for the same purpose.
>
> There are numerous operational justifications for requesting resources
> from ARIN for use outside the region and from other RIRs. The
> justification is necessary to override any assumption that the resources
> duplicate each other. The following are just a few common examples:
>
> ?* It may be necessary to use resources from another RIR to meet legal or
> regulatory requirements, or prevailing operational expectations, in some
> economies around the world. In such cases it is justified to also
> receive minimal resources from another RIR for use in those economies
> instead of using resources received from ARIN.
>
> ?* If an organization operates a connected network in some regions, but
> disconnected networks in other regions, the disconnected networks must
> receive resources from other RIRs.
>
> ?* If an organization receives resources from one or more other RIRs,
> without additional justification such as above, only an incidental
> amount of ARIN resources may be used within those regions. ARIN
> resources may be used in the other regions where resources were not
> received.
>
> Why 12.5% for incidental? First thought was simply a 90-10 rule, but
> 12.5% or 1/8th works better with powers of 2 and bit boundary prefixes.
> Example: an organization that has a /20 from ARIN can simply use up to
> a /23 outside the region, whereas 10% would result in an ugly fraction
> of 1.6 /24s, instead of the simple /23 of 12.5%. The other limits set a
> floor for each type of resource to ensure that all organizations have an
> operationally useful amount of resources for use outside the region. A
> /24 for IPv4 and a /48 for IPv6 were selected as they are fairly common
> minimum prefix sizes allowed and a fraction of an ASN doesn't make much
> sense.
>
> To facilitate X.6 it is recommended ARIN should publish and maintain a
> reference timeline of changes in the service region for ARIN and its
> predecessor registries.
>
> But we're not headquartered in the ARIN region and are using more than
> an incidental amount of ARIN resources outside the region, do we have to
> return resources? No, this policy primarily determines who is entitled
> to receive new resources from ARIN and X.3 explicitly allows you to
> continue to use those resources outside the region. However, if you are
> currently using more than 12.5% of your ARIN resources outside the ARIN
> region then going forward, you are not entitled to receive additional
> resources for use outside the ARIN region. If those resources were
> received some time ago when the services regions were different, they
> may not count against your incidental use because of X.6.
>
> Alternatives to this proposal:
>
> What if the most restrictive regional hierarchy were used instead?
> Restricting the use of all resources to only within the region of the
> RIR that allocated them. This would require an organization needing
> addresses for a single globally connected infrastructure to get five
> separate unaggregatable allocations, even if the organization would be
> willing and able to operate under a single globally aggregatable
> allocation, this should especially be possible in IPv6. This will cause
> at least some unnecessary route table growth. Additionally,
> organizations would be required to deal with all five RIRs, even if this
> doesn't provide additional value. Many organizations have only small
> needs outside one or two of the RIRs, dealing with all five RIRs may not
> provide additional value in such cases. Some organizations may not be
> able to justify minimum allocations in all five RIRs, while easily
> justifying a minimum allocation within at least one RIR or on an overall
> global basis. However, this strict interpretation of regional hierarchy
> ensures overall stewardship on a global basis.
>
> What if the most liberal regional hierarchy were used instead? Allowing
> an organization to obtain resources from one or all five RIRs and use
> those resources completely unrestricted on a global basis. This solves
> most of the drawbacks of the strict regional hierarchy. However, taken
> to an extreme, this could allow an organization to obtain as much as
> five times its justifiable global need, creating an obvious stewardship
> issue on a global basis, this is the primary drawback of this option.
> Also, it is difficult to understand what functional purpose defining
> regions actually serves with this option. Finally, with IPv4 run-out
> this option has the additional drawback of allowing completely
> unrestricted RIR shopping.
>
> Benefits to this Proposal:
>
> The RIR System was created to facilitate stewardship within the global
> Internet allowing for better interactions with users and ISPs by
> providing support during operational hours, in languages and with
> cultural understanding appropriate to and under the control of each
> region. This can only be accomplished if the RIR?s regions have at
> least some meaning. However, an overly strict interpretation of the
> regions will create operational inefficiencies for many networks and for
> the Internet as a whole in other cases. This policy creates a framework
> providing necessary flexibility for the community, while ensuring
> overall stewardship of resources on a global basis.
>
> The genesis of this policy is from the ARIN XXVII Policy Experience
> Report and the outcome of the discussions of ARIN-2011-13 at ARIN
> XXVIII. This policy is intended to be generally consistent with current
> practice and community intent while formally spelling out and clarifying
> several aspects that are currently open to interpretation.
>
> Further, this policy explicitly seeks to head off risks of RIR shopping
> based on free pool availability. Concerns regarding this were expressed
> by the community and in the ARIN XXVII Policy Experience Report.
>
> Timetable for implementation: Immediate
>
> _______________________________________________
> 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.
>

-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 3237     Holden Road |  Give me Linux  |
| babydr at baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+------------------------------------------------------------------+