[arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use)
Jason Schiller
jschiller at google.com
Mon Jul 28 11:43:19 EDT 2014
Leslie,
Would it be possible to list the number of Org IDs that hold a given amount
of /24 equivalents of ARIN IP space?
Something like:
Number of Orgs /24 equ
60 1
30 2
49 3
100 4
22 7
432 8
I think this may be a useful number in understanding how "incidental" a /20
is.
Thanks,
__Jason
On Fri, Jul 25, 2014 at 10:14 AM, Jason Schiller <jschiller at google.com>
wrote:
> I oppose as written, but support the concept.
> (I oppose this version more that the previous version)
>
> I still have concerns about the hard limit of and IPv4 /20, IPv6 /36 or
> two ASNs.
>
> I think the point here is to ensure that organizations are not double
> counting equipment to get resources from multiple RIRs for the same use,
> nor squatting on underutilized IP space from another RIR which could be
> used and instead getting additional IP space from ARIN.
>
> There was some idea in the original policy that this additional burden
> could be avoided if the out of region use was only "incidental", yielding
> this /20 text. I argued that a hard limit of a /20 is not a fair dividing
> line for incidental. Many small organizations will never need more that a
> /20. Such a large hard limit suggests that the need to prove no double
> counting or no sitting on underutilized resources from another RIR does
> not apply to small sites. Either make it a percentage of total such "When
> a request for resources from ARIN is justified by need located within
> another RIR's service region and is more than 5% of the total utilization,
> the requesting organization will also report to ARIN the utilization status
> of all resources of the same type held with any other RIR that are used or
> are available for use within the requested service region." Or simply
> always require it. If the organization does not have resources in other
> RIRs, there is no burden.
>
>
> The original proposal suggested that when ARIN validates an out of region
> use, they must be able to validate the use to no less than an equivalent
> standard as resources used within the ARIN region. This is with respect to
> ensuring the utilization is nor fraudulent, such as if the customer service
> address is a verifiable address, if the company name is an actual company,
> and so on.
>
> This proposal seems to go further and suggest that any ARIN space and
> other RIR space must be efficiently utilized by ARIN's definition of
> efficient utilization.
>
>
> "The report must demonstrate that all resources currently available for
> use within the requested service region are efficiently utilized based on
> applicable ARIN policy."
>
> If all the RIRs passed a similar policy global networks would be forced to
> follow the most strict polices of all the RIRs. In some cases the
> conflicting requirements could not be met. We had this discussion with the
> original proposal to prevent out of region use. Furthermore is flies in
> the face that regional communities have some regional autonomy to deal with
> local differences.
>
>
> I believe I could get on board with the following two changes:
>
> 1. If you drop the hard limit either making it a percentage of total use,
> or always require reporting of usage of IP space held by other RIRs
>
> 2. change " The report must demonstrate that all resources currently
> available for use within the requested service region are efficiently
> utilized based on applicable ARIN policy." to some text about ARIN
> validating out of region space no less than an equivalent standard.
> possibly "All ARIN registered resources used outside the region must be
> verified to no less than an equivalent standard as resources used within
> the ARIN region."
>
>
> ___Jason
>
>
>
> On Fri, Jul 25, 2014 at 9:01 AM, Sweeting, John <john.sweeting at twcable.com
> > wrote:
>
>> Good morning PPML,
>>
>> Please provide comments in support or opposition as the plan is to vote
>> to move this to Recommended Draft Status for the Baltimore meeting.
>>
>> Thanks,
>> John
>>
>>
>> On 7/25/14, 2:29 AM, "Milton L Mueller" <mueller at syr.edu> wrote:
>>
>> At the Chicago meeting there was support for this policy but also
>> calls for simplifying and shortening it. This is the revised version.
>>
>> ----
>>
>> Draft Policy ARIN-2014-1
>> Out of Region Use
>>
>> Date: 21 July 2014
>>
>> Problem statement:
>>
>> Current policy neither clearly forbids nor clearly permits out of region
>> use of ARIN registered resources. This has created confusion and
>> controversy within the ARIN community for some time. Earlier work on this
>> issue has restricting out of region use in various ways. None of these
>> proposals have gained consensus. The next logical option is to discuss a
>> proposal that clearly permits out of region use. Permitting out of region
>> use, however, poses issues that have to be addressed by policy and
>> adjustments to operational practice. Out of region use must be clearly
>> defined and any operational practices based on that definition must not be
>> unnecessarily burdensome. Also, it is more difficult and costly for ARIN
>> staff to independently verify the justification and utilization of
>> resources that are used outside of the ARIN service region. There needs to
>> be recognition of this difference in policy and associated operational
>> practices.
>>
>> Policy statement:
>>
>> Create new Section X;
>>
>> X. Out of region use
>>
>> ARIN registered resources may be used outside the ARIN service region and
>> such use is valid justification for new or additional resources. A resource
>> is considered to be used outside the region if it exclusively serves a
>> user, customer or technical infrastructure location outside the ARIN
>> service region.
>>
>>
>>
>> The services and facilities used to justify the need for ARIN resources
>> that will be used out of region should not also be used to justify resource
>> requests from another RIR. When a request for resources from ARIN is
>> justified by need located within another RIR's service region and is more
>> than the equivalent of a /20 for IPv4, a /36 for IPv6, or two (2) ASNs, the
>> requesting organization will also report to ARIN the utilization status of
>> all resources of the same type held with any other RIR that are used or are
>> available for use within the requested service region. The organization
>> will also supply any additional supporting documentation requested by ARIN
>> regarding the need for the reported resources. The report must demonstrate
>> that all resources currently available for use within the requested service
>> region are efficiently utilized based on applicable ARIN policy.
>>
>>
>>
>>
>> ------------------------------
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or subject to
>> copyright belonging to Time Warner Cable. This E-mail is intended solely
>> for the use of the individual or entity to which it is addressed. If you
>> are not the intended recipient of this E-mail, you are hereby notified that
>> any dissemination, distribution, copying, or action taken in relation to
>> the contents of and attachments to this E-mail is strictly prohibited and
>> may be unlawful. If you have received this E-mail in error, please notify
>> the sender immediately and permanently delete the original and any copy of
>> this E-mail and any printout.
>>
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>
--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140728/d912f85c/attachment.htm>
More information about the ARIN-PPML
mailing list