From narten at us.ibm.com Fri Sep 2 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 02 Sep 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201609020453.u824r3K1011946@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Sep 2 00:53:03 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8604 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8604 | Total From narten at us.ibm.com Fri Sep 9 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 09 Sep 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201609090453.u894r3UB030082@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Sep 9 00:53:03 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8577 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8577 | Total From farmer at umn.edu Fri Sep 9 10:50:37 2016 From: farmer at umn.edu (David Farmer) Date: Fri, 9 Sep 2016 09:50:37 -0500 Subject: [arin-ppml] Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM In-Reply-To: References: <579763D9.7010005@arin.net> Message-ID: As I said originally, "I think the Elimination of HD-Ratio is probably fairly non-controversial itself", and now I feel there has been a good discussion regarding the rewrite of Community Networks section necessary to accomplish the Elimination of HD-Ratio. There seems to be community support for this Draft Policy, no one has raised any significant concerns with the text, a Staff & Legal Assessment has been posted for this Draft Policy, see the website; https://www.arin.net/policy/proposals/2016_6.html Therefore, my intent is to move this forward to Recommended Draft Policy status at the AC meeting next week. This would allow it to be presented at the upcoming Public Policy Meeting in Dallas, and assuming there is continued support, it can move to Last Call following the meeting. So, if you have any additional comments, especially any concerns with this policy, please get them out soon. Thanks. On Mon, Aug 8, 2016 at 10:13 PM, David Farmer wrote: > As AC Shepherd, I haven't seen much discussions of this one; I think the > Elimination of HD-Ratio is probably fairly non-controversial itself. > > However, in regards to the Community Networks section, I see three > high-level alternatives for the community to consider; > > 1. Rewrite the Community Networks section to not reference HD-Ratio, > as the Draft Policy suggests; > 2. Replace the Community Networks section with a generic small ISP > policy allowing allocations of /40 (qualifying for xxx-small IPv6 fee > category); > 3. Remove the Community Networks section all together; It doesn't seem > to have been used since it was adopted, see Dan Alexander's Policy > Simplification presentation, slide #4. If we go this way, 2.11 should be > deleted also; > > https://www.arin.net/vault/participate/meetings/reports/ARIN > _37/PDF/tuesday/alexander_simplification.pdf#page=4 > > I think a rewrite in line with the original intent for the Community > Networks section is the proper place to start the conversation, and I > think this Draft Policy does a good job doing that. However since we > need to touch the Community Networks section to accomplish the > Elimination of HD-Ratio, I'd like to hear from some Community Networks to > better understand why the current policy is not being used. Is there > some problem with it? Is it just not necessary? Was it too early? Are Community > Networks just being requested and recorded as other end user requests? > > Personally, I like the idea of the Community Networks policy, but since > no one seems to be using it, maybe we should look at why as part of any > rewrite. > > Comments please, even if you simply support the policy as written. Also, > if you know someone involved in operating a Community Network please > forward this to them, I'd really like to hear from them even if they don't > want to post to PPML themselves. > > Thanks. > > > On Tue, Jul 26, 2016 at 8:21 AM, ARIN wrote: > >> On 21 July 2016, the ARIN Advisory Council (AC) advanced the following >> Proposal to Draft Policy status: >> >> ARIN-prop-231: Eliminate HD-Ratio from NRPM >> >> This Draft Policy has been numbered and titled: >> >> Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM >> >> Draft Policy ARIN-2016-6 is below and can be found at: >> >> https://www.arin.net/policy/proposals/2016_6.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will >> evaluate the discussion in order to assess the conformance of this Draft >> Policy with ARIN's Principles of Internet Number Resource Policy as stated >> in the Policy Development Process (PDP). Specifically, these principles are: >> >> > Enabling Fair and Impartial Number Resource Administration >> > Technically Sound >> > Supported by the Community >> >> The PDP can be found at: >> >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> ########## >> >> Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM >> >> Date: 26 July 2016 >> >> Problem Statement: >> >> The HD-Ratio has become an anachronism in the NRPM and some of the >> vestigial references to it create confusion about recommended prefix sizes >> for IPv6 resulting in a belief in the community that ARIN endorses the idea >> of /56s as a unit of measure in IPv6 assignments. While there are members >> of the community that believe a /56 is a reasonable choice, ARIN policy has >> always allowed and still supports /48 prefixes for any and all end-sites >> without need for further justification. More restrictive choices are still >> permitted under policy as well. This proposal does not change that, but it >> attempts to eliminate some possible confusion. >> >> The last remaining vestigial references to HD-Ratio are contained in the >> community networks policy (Section 6.5.9). This policy seeks to replace >> 6.5.9 with new text incorporating end user policy by reference (roughly >> equivalent to the original intent of 6.5.9 prior to the more recent changes >> to end-user policy). While this contains a substantial rewrite to the >> Community Networks policy, it will not have any negative impact on >> community networks. It may increase the amount of IPv6 space a community >> network could receive due to the change from HD-Ratio, but not more than >> any other similar sized end-user would receive under existing policy. >> >> Policy statement: >> >> Replace section 6.5.9 in its entirety as follows: >> >> 6.5.9 Community Network Assignments >> >> While community networks would normally be considered to be ISP type >> organizations under existing ARIN criteria, they tend to operate on much >> tighter budgets and often depend on volunteer labor. As a result, they tend >> to be much smaller and more communal in their organization rather than >> provider/customer relationships of commercial ISPs. This section seeks to >> provide policy that is more friendly to those environments by allowing them >> to use end-user criteria. 6.5.9.1 Qualification Criteria >> >> To qualify under this section, a community network must demonstrate to >> ARIN?s satisfaction that it meets the definition of a community network >> under section 2.11 of the NRPM. 6.5.9.2 Receiving Resources >> >> Once qualified under this section, a community network shall be treated >> as an end-user assignment for all ARIN purposes (both policy and fee >> structure) unless or until the board adopts a specific more favorable fee >> structure for community networks. >> >> Community networks shall be eligible under this section only for IPv6 >> resources and the application process and use of those resources shall be >> governed by the existing end-user policy contained in section 6.5.8 et. seq. >> >> Community networks seeking other resources shall remain subject to the >> policies governing those resources independent of their election to use >> this policy for IPv6 resources. >> >> Delete section 2.8 ? This section is non-operative and conflicts with the >> definitions of utilization contained in current policies. >> >> Delete section 2.9 ? This section is no longer operative. >> >> Delete section 6.7 ? This section is no longer applicable. >> >> Comments: >> >> Timetable for implementation: Immediate >> >> Anything else >> >> Originally, I thought this would be an editorial change as the HD-Ratio >> has been unused for several years. >> >> However, further research revealed that it is still referenced in the >> Community Networks policy which has also gone unused since its inception. >> As a result, I am going to attempt to simultaneously simplify the Community >> Networks policy while preserving its intent and eliminate the HD-Ratio from >> the NRPM. >> >> I realize that fees are out of scope for policy, however, in this case, >> we are not setting fees. We are addressing in policy which fee structure >> the given policy should operate under in a manner which does not constrain >> board action on actual fees. >> >> This is an attempt to preserve the original intent of the Community >> networks policy in a way that may make it less vestigial. >> >> Alternatively, we could simply delete Section 6.5.9 if that is preferred. >> The primary goal here is to get rid of vestigial reference to HD-Ratio >> rather than to get wrapped around the axle on community networks. >> _______________________________________________ >> 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. > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Sun Sep 11 17:26:37 2016 From: daveid at panix.com (David R Huberman) Date: Sun, 11 Sep 2016 17:26:37 -0400 (EDT) Subject: [arin-ppml] 2016-3: Update and request for SUPPORT or OPPOSITION Message-ID: Hello, In April, Jason Schiller and Scott Leibrand proposed a policy to allow organizations to double their IPv4 address holdings via an 8.3 or 8.4 transfer without needs justification being performed up to certain size. The draft policy text has been updated to define that "certain size" as a /16. The Shepherds believe the data shows that the vast majority of transfer requests ARIN approves are for /16 or less. Below is the text. Please indicate if you SUPPORT or OPPOSE the draft policy, or if there are some changes you'd like to see that would allow you to support it. Thank you, David Problem Statement: ARIN transfer policy currently inherits all its demonstrated need requirements for IPv4 transfers from NRPM sections 4. Because that section was written primarily to deal with free pool allocations, it is much more complicated than is really necessary for transfers. This proposal allows organizations using 80% of their current space to double their current holdings via 8.3 or 8.4 specified transfers, up to a /16 equivalent. In section 8.3, replace: The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA. with: The recipient must sign an RSA and either: - Demonstrate 80% utilization of their currently allocated space to qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16; or - Demonstrate the need for up to a 24-month supply of IP address space under current ARIN policies. In section 8.4, replace: Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space. with: Recipients within the ARIN region must either: - Demonstrate 80% utilization of their currently allocated space to qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16; or - Demonstrate the need for up to a 24-month supply of IPv4 address space under current ARIN policies. From daveid at panix.com Sun Sep 11 17:16:25 2016 From: daveid at panix.com (David R Huberman) Date: Sun, 11 Sep 2016 17:16:25 -0400 (EDT) Subject: [arin-ppml] 2016-3: Update and request for SUPPORT or OPPOSITION Message-ID: Hello, In April, Jason Schiller and Scott Leibrand proposed a policy to allow organizations to double their IPv4 address holdings via an 8.3 or 8.4 transfer without needs justification being performed up to certain size. The draft policy text has been updated to define that "certain size" as a /16. The Shepherds believe the data shows that the vast majority of transfer requests ARIN approves are for /16 or less. Below is the text. Please indicate if you SUPPORT or OPPOSE the draft policy, or if there are some changes you'd like to see that would allow you to support it. Thank you, David Problem Statement: ARIN transfer policy currently inherits all its demonstrated need requirements for IPv4 transfers from NRPM sections 4. Because that section was written primarily to deal with free pool allocations, it is much more complicated than is really necessary for transfers. This proposal allows organizations using 80% of their current space to double their current holdings via 8.3 or 8.4 specified transfers, up to a /16 equivalent. In section 8.3, replace: The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA. with: The recipient must sign an RSA and either: - Demonstrate 80% utilization of their currently allocated space to qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16; or - Demonstrate the need for up to a 24-month supply of IP address space under current ARIN policies. In section 8.4, replace: Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space. with: Recipients within the ARIN region must either: - Demonstrate 80% utilization of their currently allocated space to qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16; or - Demonstrate the need for up to a 24-month supply of IPv4 address space under current ARIN policies. From milton at gatech.edu Sun Sep 11 23:15:09 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Mon, 12 Sep 2016 03:15:09 +0000 Subject: [arin-ppml] Support for the IANA transition? Message-ID: Some of you may be aware of the fact that a certain nationalistic U.S. Senator has decided to make a campaign against the completion of the IANA transition. A subcommittee chaired by that Senator will be holding hearings September 14 (with a highly unbalanced set of views, as usual) and there may be some kind of floor vote related to the Congressional Budget Resolution this month. If you are a U.S. citizen now is the time for you to make your views known to your Senate and House representatives. Whatever your views, most congresspeople need to hear more from the technical community. You can look up your House representative by typing in your zip code here: http://ziplook.house.gov/htbin/findrep?ZIP= Similarly, you can look up your Senators and their contact information here: http://www.senate.gov/index.htm On an issue like this, which to the general public and most representatives seems very obscure, a call or email or letter from constituents can have a big impact. Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at thewire.ca Tue Sep 13 10:21:38 2016 From: kevinb at thewire.ca (Kevin Blumberg) Date: Tue, 13 Sep 2016 14:21:38 +0000 Subject: [arin-ppml] Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM In-Reply-To: References: <579763D9.7010005@arin.net>

Message-ID: <7E7773B523E82C478734E793E58F69E78E310857@SBS2011.thewireinc.local> David, I support 2016-6 and the removal of HD Ratio from the NRPM. I believe that the policy should move forward but doesn?t address concerns that I have with Community Networks. Rather than attempt to suggest revisions to this policy I have submitted a separate policy. Thanks, Kevin Blumberg From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: September 9, 2016 10:51 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM As I said originally, "I think the Elimination of HD-Ratio is probably fairly non-controversial itself", and now I feel there has been a good discussion regarding the rewrite of Community Networks section necessary to accomplish the Elimination of HD-Ratio. There seems to be community support for this Draft Policy, no one has raised any significant concerns with the text, a Staff & Legal Assessment has been posted for this Draft Policy, see the website; https://www.arin.net/policy/proposals/2016_6.html Therefore, my intent is to move this forward to Recommended Draft Policy status at the AC meeting next week. This would allow it to be presented at the upcoming Public Policy Meeting in Dallas, and assuming there is continued support, it can move to Last Call following the meeting. So, if you have any additional comments, especially any concerns with this policy, please get them out soon. Thanks. On Mon, Aug 8, 2016 at 10:13 PM, David Farmer > wrote: As AC Shepherd, I haven't seen much discussions of this one; I think the Elimination of HD-Ratio is probably fairly non-controversial itself. However, in regards to the Community Networks section, I see three high-level alternatives for the community to consider; 1. Rewrite the Community Networks section to not reference HD-Ratio, as the Draft Policy suggests; 2. Replace the Community Networks section with a generic small ISP policy allowing allocations of /40 (qualifying for xxx-small IPv6 fee category); 3. Remove the Community Networks section all together; It doesn't seem to have been used since it was adopted, see Dan Alexander's Policy Simplification presentation, slide #4. If we go this way, 2.11 should be deleted also; https://www.arin.net/vault/participate/meetings/reports/ARIN_37/PDF/tuesday/alexander_simplification.pdf#page=4 I think a rewrite in line with the original intent for the Community Networks section is the proper place to start the conversation, and I think this Draft Policy does a good job doing that. However since we need to touch the Community Networks section to accomplish the Elimination of HD-Ratio, I'd like to hear from some Community Networks to better understand why the current policy is not being used. Is there some problem with it? Is it just not necessary? Was it too early? Are Community Networks just being requested and recorded as other end user requests? Personally, I like the idea of the Community Networks policy, but since no one seems to be using it, maybe we should look at why as part of any rewrite. Comments please, even if you simply support the policy as written. Also, if you know someone involved in operating a Community Network please forward this to them, I'd really like to hear from them even if they don't want to post to PPML themselves. Thanks. On Tue, Jul 26, 2016 at 8:21 AM, ARIN > wrote: On 21 July 2016, the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status: ARIN-prop-231: Eliminate HD-Ratio from NRPM This Draft Policy has been numbered and titled: Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM Draft Policy ARIN-2016-6 is below and can be found at: https://www.arin.net/policy/proposals/2016_6.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this Draft Policy with ARIN's Principles of Internet Number Resource Policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > Enabling Fair and Impartial Number Resource Administration > Technically Sound > Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ########## Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM Date: 26 July 2016 Problem Statement: The HD-Ratio has become an anachronism in the NRPM and some of the vestigial references to it create confusion about recommended prefix sizes for IPv6 resulting in a belief in the community that ARIN endorses the idea of /56s as a unit of measure in IPv6 assignments. While there are members of the community that believe a /56 is a reasonable choice, ARIN policy has always allowed and still supports /48 prefixes for any and all end-sites without need for further justification. More restrictive choices are still permitted under policy as well. This proposal does not change that, but it attempts to eliminate some possible confusion. The last remaining vestigial references to HD-Ratio are contained in the community networks policy (Section 6.5.9). This policy seeks to replace 6.5.9 with new text incorporating end user policy by reference (roughly equivalent to the original intent of 6.5.9 prior to the more recent changes to end-user policy). While this contains a substantial rewrite to the Community Networks policy, it will not have any negative impact on community networks. It may increase the amount of IPv6 space a community network could receive due to the change from HD-Ratio, but not more than any other similar sized end-user would receive under existing policy. Policy statement: Replace section 6.5.9 in its entirety as follows: 6.5.9 Community Network Assignments While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide policy that is more friendly to those environments by allowing them to use end-user criteria. 6.5.9.1 Qualification Criteria To qualify under this section, a community network must demonstrate to ARIN?s satisfaction that it meets the definition of a community network under section 2.11 of the NRPM. 6.5.9.2 Receiving Resources Once qualified under this section, a community network shall be treated as an end-user assignment for all ARIN purposes (both policy and fee structure) unless or until the board adopts a specific more favorable fee structure for community networks. Community networks shall be eligible under this section only for IPv6 resources and the application process and use of those resources shall be governed by the existing end-user policy contained in section 6.5.8 et. seq. Community networks seeking other resources shall remain subject to the policies governing those resources independent of their election to use this policy for IPv6 resources. Delete section 2.8 ? This section is non-operative and conflicts with the definitions of utilization contained in current policies. Delete section 2.9 ? This section is no longer operative. Delete section 6.7 ? This section is no longer applicable. Comments: Timetable for implementation: Immediate Anything else Originally, I thought this would be an editorial change as the HD-Ratio has been unused for several years. However, further research revealed that it is still referenced in the Community Networks policy which has also gone unused since its inception. As a result, I am going to attempt to simultaneously simplify the Community Networks policy while preserving its intent and eliminate the HD-Ratio from the NRPM. I realize that fees are out of scope for policy, however, in this case, we are not setting fees. We are addressing in policy which fee structure the given policy should operate under in a manner which does not constrain board action on actual fees. This is an attempt to preserve the original intent of the Community networks policy in a way that may make it less vestigial. Alternatively, we could simply delete Section 6.5.9 if that is preferred. The primary goal here is to get rid of vestigial reference to HD-Ratio rather than to get wrapped around the axle on community networks. _______________________________________________ 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. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Sep 16 00:53:02 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 16 Sep 2016 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201609160453.u8G4r270016352@rotala.raleigh.ibm.com> Total of 6 messages in the last 7 days. script run at: Fri Sep 16 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 1 | 38.79% | 45194 | kevinb at thewire.ca 33.33% | 2 | 13.57% | 15811 | daveid at panix.com 16.67% | 1 | 28.29% | 32959 | farmer at umn.edu 16.67% | 1 | 12.02% | 14008 | milton at gatech.edu 16.67% | 1 | 7.32% | 8531 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 116503 | Total From info at arin.net Tue Sep 20 20:22:50 2016 From: info at arin.net (ARIN) Date: Tue, 20 Sep 2016 20:22:50 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - September 2016 Message-ID: <57E1D2DA.9070507@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 15 September 2016. The AC has advanced the following to Recommended Draft Policy status (will be posted separately as such): > ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers > ARIN-2016-2: Change timeframes for IPv4 requests to 24 months > ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy > ARIN-2016-6: Eliminate HD-Ratio from NRPM The AC advances Draft Policies to Recommended Draft Policy status once they have been fully developed and meet ARIN's Principles of Internet Number Resource Policy. Specifically, these principles are: > Enabling Fair and Impartial Number Resource Administration > Technically Sound > Supported by the Community The AC is continuing to work on: > Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy > Recommended Draft Policy ARIN-2016-4: Transfers for new entrants > Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers > ARIN-prop-232: Integration of Community Networks into existing ISP policy The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Sep 20 20:24:39 2016 From: info at arin.net (ARIN) Date: Tue, 20 Sep 2016 20:24:39 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers Message-ID: <57E1D347.70907@arin.net> On 15 September 2016, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2015_7.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers Date: 20 September 2016 AC's assessment of conformance with the Principles of Internet Number Resource Policy: 2015-7 is one of a set of overlapping policies involving simplification of section 8 specified transfer policy. Each takes a somewhat different approach, and all have a degree of community support. Based on community feedback at the upcoming ARIN 38 meeting in Dallas, we hope to advance whichever of those proposals is best-supported by the community, or craft and advance a unified proposal that incorporates the best attributes of the proposals currently on the docket. Moving 2015-7 to Recommended Draft will facilitate moving the best policy forward in a timely manner. Problem statement: ARIN transfer policy currently inherits all its demonstrated need requirements for IPv4 transfers from NRPM sections 4. Because that section was written primarily to deal with free pool allocations, it is much more complicated than is really necessary for transfers. In practice, ARIN staff applies much more lenient needs assessment to section 8 IPv4 transfer requests than to free pool requests, as 24-month needs are much more difficult to assess to the same level of detail. This proposal seeks to dramatically simplify the needs assessment process for 8.3 transfers, while still allowing organizations with corner-case requirements to apply under existing policy if necessary. Policy statement: Append the follwing bullet point to "Conditions on recipient of the transfer" section in NRPM 8.3 and 8.4 A recipient of IPv4 number resources may, at its option, demonstrate need by having an officer of the requesting organization attest that they will use at least 50% of their aggregate IPv4 addresses (including the requested resources) on an operational network within 24 months, rather than the criteria enumerated in Section 4 of the NRPM. Comments: a. Timetable for implementation: Immediate b. Anything else From info at arin.net Tue Sep 20 20:26:02 2016 From: info at arin.net (ARIN) Date: Tue, 20 Sep 2016 20:26:02 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months Message-ID: <57E1D39A.9010809@arin.net> On 15 September 2016, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2016-2: Change timeframes for IPv4 requests to 24 months The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2016_2.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months Date: 20 September 2016 AC's assessment of conformance with the Principles of Internet Number Resource Policy: 2016-2 is one of a set of overlapping policies involving simplification of section 8 specified transfer policy. Each takes a somewhat different approach, and all have a degree of community support. Based on community feedback at the upcoming ARIN 38 meeting in Dallas, we hope to advance whichever of those proposals is best-supported by the community, or craft and advance a unified proposal that incorporates the best attributes of the proposals currently on the docket. Moving 2016-2 to Recommended Draft will facilitate moving the best policy forward in a timely manner. Problem Statement: Disparity in timeframes between pre-approvals for waiting list and pre-approval for transfers is creating difficulties for organizations that initially apply to be on the waiting list and subsequently elect to satisfy their needs through transfers. Therefore, this proposal seeks to set all timeframes for IPv4 request approvals to 24 months. Prior to runout, such a change could have created great disparity in resource distribution just because of coincidence of request timing. With the free pool gone, this is no longer an issue. Policy statement: The following changes would be made in the NRPM: 1. Retitle section 4.2.2.1.3 ?Three months? to ?Time Horizon?. 2. Section 4.2.2.1.3 body, replace ?three months? with ?24 months?. 3. Section 4.2.3.8, replace the term ?three months? with ?24 months?. 4. Section 4.3.3, replace both instances of ?one year? with ?24 months?. 5. Section 4.2.4.3, replace the entire paragraph which currently reads: "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate allocation to be issued is based on efficient utilization of space within this time frame, consistent with the principles in 4.2.1.? with: ?ISPs may request up to a 24-month supply of IPv4 addresses.? Comments: a. Timetable for implementation: Immediate b. Clarification of intent - This policy would not affect the existing waiting list in any way. This policy would simply change the qualification period to 24 months, so new entrants can go to either the bottom of the waiting list or to the transfer market to seek their 24-month supply. If an existing entity on the waiting list wants to re-qualify and expand their request to a 24-month supply, they would go to the end of the list. Otherwise, they would remain on the waiting list with the original approved block size unchanged. If the organization's needs have changed by the time IPv4 space becomes available to fill waiting list requests, the organization will be re-qualified under the new more lenient 24-month standard, but regardless of re-qualification, the organization will not be eligible to receive a larger block than they originally qualified for when they were placed on the waiting list. From info at arin.net Tue Sep 20 20:27:41 2016 From: info at arin.net (ARIN) Date: Tue, 20 Sep 2016 20:27:41 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy Message-ID: <57E1D3FD.4050404@arin.net> On 15 September 2016, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2016_5.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy Date: 20 September 2016 AC's assessment of conformance with the Principles of Internet Number Resource Policy: 2016-5 is one of a set of overlapping policies involving simplification of section 8 specified transfer policy. Each takes a somewhat different approach, and all have a degree of community support. Based on community feedback at the upcoming ARIN 38 meeting in Dallas, we hope to advance whichever of those proposals is best-supported by the community, or craft and advance a unified proposal that incorporates the best attributes of the proposals currently on the docket. Moving 2016-5 to Recommended Draft will facilitate moving the best policy forward in a timely manner. Problem Statement: Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN?s inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers. Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers. Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM. The goals of this rewrite are as follows: - Separate the criteria that is found in section 4 of the NRPM from the transfer process. - Provide a clear set of criteria that should be applied across all IPv4 transfers. - Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM. - Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing. Policy statement: Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5. 8.2. Mergers, Acquisitions, and Reorganizations ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions: - The current registrant must not be involved in any dispute as to the status of the resources to be transferred. - The new entity must sign an RSA covering all resources to be transferred. - The resources to be transferred will be subject to ARIN policies. - The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy. - For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation. ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN. 8.3. Transfers between Specified Recipients within the ARIN Region In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions. Conditions on source of the transfer: - The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. Conditions on recipient of the transfer: - The recipients must meet the transfer requirements as defined in section 8.5. - The resources transferred will be subject to current ARIN policies. 8.4. Inter-RIR Transfers to Specified Recipients Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies. Conditions on source of the transfer: - The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources. - Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration. - Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. Conditions on recipient of the transfer: - The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. - Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5. - Recipients within the ARIN region will be subject to current ARIN policies. 8.5. Specified Transfer Recipient Requirements 8.5.1. Registration Services Agreement The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file. 8.5.2. Operational Use ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network. 8.5.3. Minimum transfer size ARIN?s minimum IPv4 transfer size is a /24. 8.5.4. Initial block Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARIN?s minimum transfer size. 8.5.5. Block size Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN. 8.5.6. Efficient utilization of previous blocks Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers. Comments: Timetable for implementation: immediately Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM. From info at arin.net Tue Sep 20 20:28:20 2016 From: info at arin.net (ARIN) Date: Tue, 20 Sep 2016 20:28:20 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM Message-ID: <57E1D424.4030504@arin.net> On 15 September 2016, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2016-6: Eliminate HD-Ratio from NRPM The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2016_6.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM Date: 20 September 2016 AC's assessment of conformance with the Principles of Internet Number Resource Policy: This proposal is technically sound and enables fair and impartial number policy by reducing any confusion caused by HD-Ratio remaining in the NRPM. According to the staff and legal assessment, these changes align with current practice of ARIN staff. There is support and no concerns have been raised by the community regarding this proposal on PPML. Problem Statement: The HD-Ratio has become an anachronism in the NRPM and some of the vestigial references to it create confusion about recommended prefix sizes for IPv6 resulting in a belief in the community that ARIN endorses the idea of /56s as a unit of measure in IPv6 assignments. While there are members of the community that believe a /56 is a reasonable choice, ARIN policy has always allowed and still supports /48 prefixes for any and all end-sites without need for further justification. More restrictive choices are still permitted under policy as well. This proposal does not change that, but it attempts to eliminate some possible confusion. The last remaining vestigial references to HD-Ratio are contained in the community networks policy (Section 6.5.9). This policy seeks to replace 6.5.9 with new text incorporating end user policy by reference (roughly equivalent to the original intent of 6.5.9 prior to the more recent changes to end-user policy). While this contains a substantial rewrite to the Community Networks policy, it will not have any negative impact on community networks. It may increase the amount of IPv6 space a community network could receive due to the change from HD-Ratio, but not more than any other similar sized end-user would receive under existing policy. Policy statement: Replace section 6.5.9 in its entirety as follows: 6.5.9 Community Network Assignments While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide policy that is more friendly to those environments by allowing them to use end-user criteria. 6.5.9.1 Qualification Criteria To qualify under this section, a community network must demonstrate to ARIN?s satisfaction that it meets the definition of a community network under section 2.11 of the NRPM. 6.5.9.2 Receiving Resources Once qualified under this section, a community network shall be treated as an end-user assignment for all ARIN purposes (both policy and fee structure) unless or until the board adopts a specific more favorable fee structure for community networks. Community networks shall be eligible under this section only for IPv6 resources and the application process and use of those resources shall be governed by the existing end-user policy contained in section 6.5.8 et. seq. Community networks seeking other resources shall remain subject to the policies governing those resources independent of their election to use this policy for IPv6 resources. Delete section 2.8 ? This section is non-operative and conflicts with the definitions of utilization contained in current policies. Delete section 2.9 ? This section is no longer operative. Delete section 6.7 ? This section is no longer applicable. Comments: Timetable for implementation: Immediate Anything else Originally, I thought this would be an editorial change as the HD-Ratio has been unused for several years. However, further research revealed that it is still referenced in the Community Networks policy which has also gone unused since its inception. As a result, I am going to attempt to simultaneously simplify the Community Networks policy while preserving its intent and eliminate the HD-Ratio from the NRPM. I realize that fees are out of scope for policy, however, in this case, we are not setting fees. We are addressing in policy which fee structure the given policy should operate under in a manner which does not constrain board action on actual fees. This is an attempt to preserve the original intent of the Community networks policy in a way that may make it less vestigial. Alternatively, we could simply delete Section 6.5.9 if that is preferred. The primary goal here is to get rid of vestigial reference to HD-Ratio rather than to get wrapped around the axle on community networks. From narten at us.ibm.com Fri Sep 23 00:53:02 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 23 Sep 2016 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201609230453.u8N4r3GL022200@rotala.raleigh.ibm.com> Total of 6 messages in the last 7 days. script run at: Fri Sep 23 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 83.33% | 5 | 84.81% | 47822 | info at arin.net 16.67% | 1 | 15.19% | 8568 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 56390 | Total From narten at us.ibm.com Fri Sep 30 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 30 Sep 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201609300453.u8U4r3aK004195@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Sep 30 00:53:03 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8361 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8361 | Total From rfg at tristatelogic.com Fri Sep 30 09:15:38 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 30 Sep 2016 06:15:38 -0700 Subject: [arin-ppml] Fraud Policy ? Message-ID: <65339.1475241338@segfault.tristatelogic.com> I got a policy question. Well, a couple, actually. For the time being it will be Best if I couch my question(s) in terms of a hypothetical. Assume, hypothetically, just for the sake of argument, that there exists a valid legal entity `A' which has already performed all of the appropriate formalities and rituals necessary to legitimately obtain from ARIN some set of number resources. Assume further that at some later date, some other party `B' comes along and fradulently pretends to be the legal entity `A' and by so doing, obtains some additional number resources from ARIN. (Assume also that thereafter, party `B' does in fact makes use of these fradulently obtained number resources.) I would like to try to understand how existing ARIN policies might bear on the above hypothetical scenario. Specifically, I'd like to obtain answers to the following: 1) What sorts of documents, exactly, must either party `A' or party `B' in the above scenario submit to ARIN in order to establish their bona fides to ARIN's satisfaction? 2) In a case such as the one described above, if it is later determined... let's just say beyond a reasonable doubt... that party `B' has in fact made one or more fradulent representations to ARIN staff, and by so doing, party `B' has obtained from ARIN staff some finite non-zero quanta of number resources, then which of the following actions must, may, or will ARIN staff undertake in such a situation? (I am asking what the applicable current/existing formalized written policy demands in such a circumstances.) a) ARIN will report the fraud to law enforcement b) ARIN will initiate civil legal action against party `B' c) both of the above d) none of the above Regards, rfg P.S. To me clear, it is not my desire to either generate or to participate in any debate about what sorts of policies ARIN staff should actually follow in such scenarios. I believe that my own preferences are already well known to almost everybody who knows me, and I doubt that I have the capacity to change anyone's mind who hold a different view. (For those of you who do not know me, I'll just say that my personal preferences are to have any and all parties caught engaging in such hanky panky hanged at sunrise, and thereafter shot also, just to be on the safe side. But I respect any and all who hold a different view on this point.) From jcurran at arin.net Fri Sep 30 13:42:07 2016 From: jcurran at arin.net (John Curran) Date: Fri, 30 Sep 2016 17:42:07 +0000 Subject: [arin-ppml] Fraud Policy ? In-Reply-To: <65339.1475241338@segfault.tristatelogic.com> References: <65339.1475241338@segfault.tristatelogic.com> Message-ID: <0FFFCD2A-863A-4D3D-9E41-13EFE5988E53@corp.arin.net> On 30 Sep 2016, at 9:15 AM, Ronald F. Guilmette wrote: > > I got a policy question. Well, a couple, actually. > > For the time being it will be Best if I couch my question(s) in > terms of a hypothetical. > > Assume, hypothetically, just for the sake of argument, that there > exists a valid legal entity `A' which has already performed all of > the appropriate formalities and rituals necessary to legitimately > obtain from ARIN some set of number resources. Assume further > that at some later date, some other party `B' comes along and > fradulently pretends to be the legal entity `A' and by so doing, > obtains some additional number resources from ARIN. (Assume also > that thereafter, party `B' does in fact makes use of these fradulently > obtained number resources.) > > I would like to try to understand how existing ARIN policies might > bear on the above hypothetical scenario. Specifically, I'd like to > obtain answers to the following: > > 1) What sorts of documents, exactly, must either party `A' or party > `B' in the above scenario submit to ARIN in order to establish their > bona fides to ARIN's satisfaction? At a minimum, Incorporation documents which align with their state registration. Additional information will likely be required, depending on the circumstances. > 2) In a case such as the one described above, if it is later determined... > let's just say beyond a reasonable doubt... that party `B' has in fact > made one or more fradulent representations to ARIN staff, and by so > doing, party `B' has obtained from ARIN staff some finite non-zero > quanta of number resources, then which of the following actions must, > may, or will ARIN staff undertake in such a situation? (I am asking > what the applicable current/existing formalized written policy demands > in such a circumstances.) > > a) ARIN will report the fraud to law enforcement > b) ARIN will initiate civil legal action against party `B' > c) both of the above > d) none of the above Yes. ARIN may do any/all of the above, including ?e) revoking number resources obtained fraudulently? with respect to party ?B? The specific actions are not governed by policy, aside from the references in NRPM section 12. Thanks, /John John Curran President and CEO ARIN From chris at semihuman.com Fri Sep 30 13:52:58 2016 From: chris at semihuman.com (Chris Woodfield) Date: Fri, 30 Sep 2016 10:52:58 -0700 Subject: [arin-ppml] Fraud Policy ? In-Reply-To: <0FFFCD2A-863A-4D3D-9E41-13EFE5988E53@corp.arin.net> References: <65339.1475241338@segfault.tristatelogic.com> <0FFFCD2A-863A-4D3D-9E41-13EFE5988E53@corp.arin.net> Message-ID: <03BDECBE-089F-4742-ACD5-25C17F6230E2@semihuman.com> > > Yes. ARIN may do any/all of the above, including ?e) revoking > number resources obtained fraudulently? with respect to party ?B? > The specific actions are not governed by policy, aside from the > references in NRPM section 12. > I?m really curious as to the mechanics of revoking a fraudulent allocation/assignment. Do RIRs have any contractual or other legal power to stop a prefix from being announced by an ASN (and accepted by upstream networks)? Or do we have to just trust providers to filter out an inbound BGP advertisement upon notification that it?s fraudulent? -C > Thanks, > /John > > John Curran > President and CEO > ARIN > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Fri Sep 30 16:23:42 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 30 Sep 2016 13:23:42 -0700 Subject: [arin-ppml] Fraud Policy ? In-Reply-To: <0FFFCD2A-863A-4D3D-9E41-13EFE5988E53@corp.arin.net> Message-ID: <66661.1475267022@segfault.tristatelogic.com> I just want to take a moment and say how much I appreciate John Curran's speedy reply to my two questions. Coming from him, I feel sure that I have answers which are coming straight from the proverbial horse's mouth, as it were. Thanks John! I resopond briefly below. In message <0FFFCD2A-863A-4D3D-9E41-13EFE5988E53 at corp.arin.net>, John Curran wrote: >> 1) What sorts of documents, exactly, must either party `A' or party >> `B' in the above scenario submit to ARIN in order to establish their >> bona fides to ARIN's satisfaction? >At a minimum, Incorporation documents which align with their state >registration. Additional information will likely be required, depending >on the circumstances. The above answer is, of course, entirely sensible. But I've just now realized that I may have actually asked the wrong question. Naturally, when a -new- legal entity shows up at the door of ARIN, asking to be let in, ARIN is going to do some good and proper due diligence to see that they are who they say they are. But the scenario I described is a bit different. In that scenario, party `B' shows up at ARIN's door -pretending- to be the already-vetted party `A', and then proceeds to request ``additional'' number resources, i.e. either additional AS numbers, or additional IP blocks or both. (The newly-allocated numbers would then be formally assigned by ARIN to party `A', but it seems at least theoretically possible that `A' might not even find out about these supplimental allocations, thus leaving party `B' free to do as it will with them.) I had actually intended to ask about ARIN's process for vetting these kinds of ``supplimental'' allocations, but thinking about it now I've just realized that actually, I'm not sure that I want to know, or rather, I'm fairly sure that I -do not- want John to elaborate in any detail on the internal processes used to vet supplimental allocation requests. Not in public anyway. If there's one thing that both history and recent current events has taught me it is that in order for any party to ``beat'' he system, that party first has to know the system. For this reason it is probably better that the fine details of ARIN's vetting processes should be left unspoken. But with respect to the ``supplimental allocation'' scenario I've described, I will just offer up the (naive?) observation that I suspect that supplimental allocation requests are, most likely, not subjected to quite the same level of scrutiny as are original/primary allocation requests. (That is almost certainly both reasonable and unavoidable. I doubt that ARIN members would like being asked to prove their identities all over again for each additional allocation request. That would be neither convenient nor terribly practical.) Regarding my second question, I asked if there was any existing written policy covering ARIN's actions in cases where it might see evidence of bald faced fraud, and asked specifically about these four possibilities: > a) ARIN will report the fraud to law enforcement > b) ARIN will initiate civil legal action against party `B' > c) both of the above > d) none of the above Once again I thank John for providing a crisp, clear, and on-point response. John said that ARIN may do any of the above, and that the actions taken in any given case are not, at present, governed by written policy. I actually find that all to be quite reasonable, and having already said that my goal was neither to create debate about any of this, nor to participate in any such debate that might arise as a result of my questions, I do feel constrained by that earlier comment. Nontheless, I can't help but put forward some modest suggestions for minor changes: 1) I think it would be Good if ARIN had at least some written policy with respect to fraud, even if that was only very minimal. ARIN has been the victim of fraud on multiple occasions in the past, and given the both the incentives and the increasingly chaotic nature of life on the Internet, I believe that this is likely to be an issue in the future as well. 2) With respect to civil litigation, I am personally and painfully aware of the old saying ``You can't get blood out of a turnip'', and that thus, civil litigation is often just not worth it. Thus I think that it is eminently appropriate to leave decisions about civil litigation entirely up to to the good judgement and discretion of John and his colleagues. That having been said however, my personal preference would be to have in place a formal ARIN policy which would unambiguously direct ARIN management to file a formal report with law enforcement in each and every case where the available facts indicate that there is probably cause to believe that criminal fraud has occured. Borrowing from the language of the RFCs, I would prefer to see this converted from a MAY to a MUST. Any fraudster who is intent upon deceiving ARIN in a material way should have no illusions that his actions will go unreported. Regards, rfg From jcurran at arin.net Fri Sep 30 18:23:56 2016 From: jcurran at arin.net (John Curran) Date: Fri, 30 Sep 2016 22:23:56 +0000 Subject: [arin-ppml] Fraud Policy ? In-Reply-To: <03BDECBE-089F-4742-ACD5-25C17F6230E2@semihuman.com> References: <65339.1475241338@segfault.tristatelogic.com> <0FFFCD2A-863A-4D3D-9E41-13EFE5988E53@corp.arin.net> <03BDECBE-089F-4742-ACD5-25C17F6230E2@semihuman.com> Message-ID: <2DAF4117-4220-4658-BED9-B5BA08DA701C@arin.net> On 30 Sep 2016, at 1:52 PM, Chris Woodfield > wrote: Yes. ARIN may do any/all of the above, including ?e) revoking number resources obtained fraudulently? with respect to party ?B? The specific actions are not governed by policy, aside from the references in NRPM section 12. I?m really curious as to the mechanics of revoking a fraudulent allocation/assignment. Do RIRs have any contractual or other legal power to stop a prefix from being announced by an ASN (and accepted by upstream networks)? Chris - ARIN does not control routing of number resources; that is entirely up to the ISP community. As it probably obvious, the usefulness of an Internet number registry is only going to be as good as the routing practices of those who choose to follow it... /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: