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


More information about the ARIN-PPML mailing list