From narten at us.ibm.com Fri Oct 7 00:53:02 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 07 Oct 2016 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201610070453.u974r2Pi022954@rotala.raleigh.ibm.com> Total of 6 messages in the last 7 days. script run at: Fri Oct 7 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 2 | 32.02% | 23413 | jcurran at arin.net 33.33% | 2 | 24.59% | 17981 | rfg at tristatelogic.com 16.67% | 1 | 32.03% | 23424 | chris at semihuman.com 16.67% | 1 | 11.36% | 8304 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 73122 | Total From narten at us.ibm.com Fri Oct 14 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 14 Oct 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201610140453.u9E4r3D8031702@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Oct 14 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8530 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8530 | Total From Daniel_Alexander at comcast.com Sat Oct 15 23:16:41 2016 From: Daniel_Alexander at comcast.com (Alexander, Daniel) Date: Sun, 16 Oct 2016 03:16:41 +0000 Subject: [arin-ppml] Upcoming Public Policy Discussions In-Reply-To: References: Message-ID: Hello Everyone, We are going to discuss a number of policies next week at the Public Policy Meeting in Dallas. Four of these proposals are focused on transfers and needs assessment, each suggesting changes using a different approach. To try and help the discussions, the AC wanted to put a comparison chart together to compliment the discussion guide. The attached chart will be provided to people attending the discussions in person. We wanted to provide this chart to the mailing list as well, for those who cannot make it to the meeting. Please let the Shepherds know your thoughts about these suggested changes. Related proposals: ARIN 2015-7 Simplified Requirements for Demonstrated Need for IPv4 Transfers ARIN 2016-3 Alternative Simplified Criteria for Justifying Small IPv4 Transfers ARIN 2016-4 Transfers for New Entrants ARIN 2016-5 Post IPv4 Free Pool Depletion Transfer Policy Needed feedback: - Is it useful to break the dependency between section 4 and section 8? - Is it useful to simplify the transfer requirements? - Are the needs requirements in any of the proposals too lax, or too restrictive? - Do people prefer one approach over another? Which ones? Please let the AC Shepherds know your thoughts on these topics. Thank you Dan Alexander AC Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Transfer Policy Proposal Comparison Chart.pdf Type: application/pdf Size: 60412 bytes Desc: Transfer Policy Proposal Comparison Chart.pdf URL: From andrew.dul at quark.net Tue Oct 18 16:55:53 2016 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 18 Oct 2016 15:55:53 -0500 Subject: [arin-ppml] Upcoming Public Policy Discussions In-Reply-To: References: Message-ID: With my community member and author hats on. And in attempt to start this conversation before the formal meeting starts on Thursday. > On Oct 15, 2016, at 22:16, Alexander, Daniel wrote: > > > > Related proposals: > > ARIN 2015-7 Simplified Requirements for Demonstrated Need for IPv4 Transfers > ARIN 2016-3 Alternative Simplified Criteria for Justifying Small IPv4 Transfers > ARIN 2016-4 Transfers for New Entrants > ARIN 2016-5 Post IPv4 Free Pool Depletion Transfer Policy > > Needed feedback: > > - Is it useful to break the dependency between section 4 and section 8? Yes, I believe that the rules that were developed for managing the free pool are not as applicable when IPv4 number resources are being transferred in the marketplace. Simplifying the transfer requirements by breaking the linkage to section 4, I think is the best path forward. > - Is it useful to simplify the transfer requirements? Yes, I believe simpler rules would benefit the community by providing additional clarity on transfers and also can provide better predictability for organizations which decide to purchase IPv4 number rights. > - Are the needs requirements in any of the proposals too lax, or too restrictive? > - Do people prefer one approach over another? Which ones? As the author of 2016-5, I believe this policy provides the best path forward. I also support the ideas in 2015-7, but I believe further work would still be needed if this policy was the only change. I don't support 2016-3 as this policy does not deal with the clarity needed for the largest transfers. 2016-4 is complementary and overlapping change to 2016-5 and thus I support that change, although I believe the larger change of 2016-5 is preferable. Andrew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Tue Oct 18 19:54:15 2016 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 18 Oct 2016 16:54:15 -0700 Subject: [arin-ppml] Upcoming Public Policy Discussions In-Reply-To: References: Message-ID: <67c79971-03c4-8531-ff74-6da8aa42786c@linuxmagic.com> I have one comment.. Having had recent discussions on the current policies, it is important that all policies have synergy.. In ARIN-2016-5, we speak of.. "Efficient utilization of at least 50% of cumulative IPv4 address blocks already assigned to them" I believe this should be extended to also include that the current registrant MUST be compliant with existing policies regarding the proper use of SWIP or 'rwhois' for any IP space they currently operate, insofar as that space is relegated to other parties. It should also require that all existing POC information is correct and up to date. And if they have a reference to a 'rwhois' server, it should be operating, functional and accurate. Even some of the largest provider(s) do not seem to conform to ARIN guidelines, and the transfer process should not be started, unless current networks are in compliance.. Not to pick on Time Warner, it was just recently reported to me, so fresh in my mind.. eg.. NetRange: 97.76.0.0 - 97.79.255.255 CIDR: 97.76.0.0/14 NetName: RCSW NetHandle: NET-97-76-0-0-1 Parent: NET97 (NET-97-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Time Warner Cable Internet LLC (RCSW) .... Comment: Allocations for this OrgID serve Road Runner commercial customers out of the Austin, TX and Tampa Bay, FL RDCs. .... Found a referral to rwhois.rr.com:4321. connect: Connection refused So, at it simplest, I would see that amended to read.. "Accurate record keeping, and efficient utilization of .." On 16-10-15 08:16 PM, Alexander, Daniel wrote: > Hello Everyone, > > We are going to discuss a number of policies next week at the Public > Policy Meeting in Dallas. Four of these proposals are focused on > transfers and needs assessment, each suggesting changes using a > different approach. To try and help the discussions, the AC wanted to > put a comparison chart together to compliment the discussion guide. > > The attached chart will be provided to people attending the discussions > in person. We wanted to provide this chart to the mailing list as well, > for those who cannot make it to the meeting. Please let the Shepherds > know your thoughts about these suggested changes. > > Related proposals: > > ARIN 2015-7 Simplified Requirements for Demonstrated Need for IPv4 Transfers > ARIN 2016-3 Alternative Simplified Criteria for Justifying Small IPv4 > Transfers > ARIN 2016-4 Transfers for New Entrants > ARIN 2016-5 Post IPv4 Free Pool Depletion Transfer Policy > > Needed feedback: > > - Is it useful to break the dependency between section 4 and section 8? > - Is it useful to simplify the transfer requirements? > - Are the needs requirements in any of the proposals too lax, or too > restrictive? > - Do people prefer one approach over another? Which ones? > > Please let the AC Shepherds know your thoughts on these topics. > > Thank you > Dan Alexander > AC Chair > > > _______________________________________________ > 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. > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From rfg at tristatelogic.com Wed Oct 19 00:53:50 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 18 Oct 2016 21:53:50 -0700 Subject: [arin-ppml] Upcoming Public Policy Discussions In-Reply-To: <67c79971-03c4-8531-ff74-6da8aa42786c@linuxmagic.com> Message-ID: <32872.1476852830@segfault.tristatelogic.com> In message <67c79971-03c4-8531-ff74-6da8aa42786c at linuxmagic.com>, Michael Peddemors wrote: >In ARIN-2016-5, we speak of.. > >"Efficient utilization of at least 50% of cumulative IPv4 >address blocks already assigned to them" > >I believe this should be extended to also include that the current >registrant MUST be compliant with existing policies regarding the proper >use of SWIP or 'rwhois' for any IP space they currently operate, insofar >as that space is relegated to other parties. > >It should also require that all existing POC information is correct and >up to date. And if they have a reference to a 'rwhois' server, it >should be operating, functional and accurate. Not that my opinion counts for anything, but I would like to second all of the above. While reseaching snowshoe spammers and other even worse flavors of net-miscreants, on an essentially daily basis I come across rwhois servers that are either entirely dead or that are live but that say nothing in response to any query sent to them... at least ones about currently live spammer ranges. The problem is so bad, and I see it with such frequency, that these days I just shrug and assume that it's just one more service provider that I should add to my ever growing list of ones that can be bribed into applying the rwhois version of whiteout to certain ranges. Not that either rwhois data or explicit SWIP data... when those -are- actually available... routinely bear any cognizable relationship to actual factually-established reality mind you. In addition to data being just plain unavailiable, I also see utter garbage in both rwhois records and in sub-SWIPs virtually every day. In theory I could while away my days reporting all of this stuff... to whom, I'm not even sure, cuz the evidence from where I'm sitting suggests that nobody gives a damn, or if they do, they are so constrained that they can't do anything about it... but anyway, I have to eat and sleep, and take a shower occasionally, and even if I could devote myself 24/7/365 to the task, I'm not sure that I could even make a dent in it. The problem really is THAT big now. There's a separate and related problem too. In a lot of cases, even when contact data is "accurate", it isn't. A UPS mailbox is not a place of business, nor is one at one's local Internet Exchange. But exactly such phony baloney bovine excrement apparently passes muster, accoring to the letter of the rules, so dodgy non-entities continue to exploit the cracks in the minimalist formal rules, and as they do, the job of actually being able to identify any actor, either bad or good, on the Internet becomes a more hopeless task by the day. (I look forward to the day when somebody sends me a picture of a miniature desk, with matching miniature chair, phone, computer, keyboard, monitor and office worker, all somehow magically stuffed into a 2 inch by 2 inch slot the size of an anonymizing UPS mail drop box.) I doubt that I'm saying anything that law enforcement hasn't already said, in one way or another. But perhaps I am. I seriously doubt that even all of LE in North America, taken together, have tried to find the true current users of as many different IPv4 addresses and ranges as I have, over time. So even they may not know just how bad things have gotten. I wish that it were otherwise. If the transfer of resources might serve as a time, or as an excuse, to get even some of this mess cleaned up, then I for one am all for it. Regards, rfg From narten at us.ibm.com Fri Oct 21 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 21 Oct 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201610210453.u9L4r3Ua018626@rotala.raleigh.ibm.com> Total of 5 messages in the last 7 days. script run at: Fri Oct 21 00:53:03 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 1 | 58.88% | 175543 | daniel_alexander at comcast.com 20.00% | 1 | 32.02% | 95468 | andrew.dul at quark.net 20.00% | 1 | 3.36% | 10015 | michael at linuxmagic.com 20.00% | 1 | 2.95% | 8788 | rfg at tristatelogic.com 20.00% | 1 | 2.79% | 8311 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 5 |100.00% | 298125 | Total From Alison.WOOD at oregon.gov Mon Oct 24 13:24:25 2016 From: Alison.WOOD at oregon.gov (WOOD Alison * DAS) Date: Mon, 24 Oct 2016 17:24:25 +0000 Subject: [arin-ppml] Thank you! Message-ID: Good morning! It was wonderful to see so many of you at ARIN 38 in Dallas!! I truly appreciate your support and vote in my efforts to join the ARIN Advisory Council. The polls are open until Friday so there is still plenty of time to vote! https://arin.net/participate/elections/index.html Thank you very much!! Alison Wood State of Oregon ARIN Advisory Council Candidate -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Oct 25 10:33:15 2016 From: jcurran at arin.net (John Curran) Date: Tue, 25 Oct 2016 14:33:15 +0000 Subject: [arin-ppml] Thank you! In-Reply-To: References: Message-ID: <8FA4B6D2-FA8E-4AB1-8D2F-945D815C5C62@arin.net> Alison - A quick reminder - ?In order to prevent list abuse and subscriber spam, candidates may not use ARIN mailing or member lists for campaign purposes.? Thanks! /John John Curran President and CEO ARIN On 24 Oct 2016, at 7:24 PM, WOOD Alison * DAS > wrote: Good morning! It was wonderful to see so many of you at ARIN 38 in Dallas!! I truly appreciate your support and vote in my efforts to join the ARIN Advisory Council. The polls are open until Friday so there is still plenty of time to vote! https://arin.net/participate/elections/index.html Thank you very much!! Alison Wood State of Oregon ARIN Advisory Council Candidate _______________________________________________ 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 info at arin.net Wed Oct 26 17:02:28 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:02:28 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - October 2016 Message-ID: <581119E4.4070005@arin.net> The Advisory Council met on 21 October in accordance with the Policy Development Process (PDP), and moved the following to Last Call (each will be posted separately): 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-2: Change timeframes for IPv4 requests to 24 months Recommended Draft Policy ARIN-2016-4: Transfers for new entrants Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM The AC abandoned the following: Recommended Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers The AC provided the following statement regarding ARIN-2015-7: The Advisory Council decided to abandon ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers due to a lack of support, when compared to other alternative proposals at the Public Policy Meeting at ARIN 38 in Dallas. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. The AC accepted the following Proposal as a Draft Policy (to be posted separately for discussion): ARIN-prop-232: Integration of Community Networks into existing ISP policy The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to number resource policy text. The AC is continuing to work on: Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers The AC provided the following statement regarding ARIN-2016-3: With regard to merging with other Recommended Draft Policies, 2016-3 includes a change to NRPM Section 8.4, bullet 3. Recommended Draft Policy ARIN-2016-5 includes the movement of bullet 3 to bullet 2. Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy includes the addition of a bullet to Section 8.4 Should 2016-5 be implemented, the aforementioned changes from 2016-3 and 2016-1 should be incorporated into Section 4 as appropriate. 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 Wed Oct 26 17:12:08 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:12:08 -0400 Subject: [arin-ppml] Draft Policy ARIN-2016-7: Integration of Community Networks into existing ISP policy Message-ID: <58111C28.7050201@arin.net> On 21 October 2016 the ARIN Advisory Council (AC) advanced ARIN-prop-232 to Draft Policy status. This Draft Policy has been numbered and titled: Draft Policy ARIN-2016-7: Integration of Community Networks into existing ISP policy Draft Policy ARIN-2016-7 is below and can be found at: https://www.arin.net/policy/proposals/2016_7.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-7: Integration of Community Networks into existing ISP policy Problem Statement: The current Community Networks (Section 6.5.9) has not been utilized by organizations. The definition of a Community Network is overly narrow in scope and has complicated requirements. The existing text does not specify whether an Organization will be considered an end-user or ISP. This policy change would relax the definition of a Community Network, while still retaining modest controls. As well it would integrate the key components into the existing policy without requiring a specific section. Policy statement: Current NRPM Text 2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers. New NRPM Text 2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit or equivalent organization or accredited educational institution for the purpose of providing free or low-cost connectivity in their local service area. Current NRPM Text 6.5.2.1 (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more than a /16 initial allocation. New NRPM Text 6.5.2.1 (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more than a /16 initial allocation. A Community Network may request a /48 or larger depending on qualification. Add to NRPM 6.5.2.2 (d) A Community Network that does not qualify under the previous requirements can provide a plan detailing anticipated assignments to users for one, two and five year periods, with a minimum of 50 assignments within 5 years. Remove Section 6.5.9 from NRPM Comments: Timetable for implementation: Immediate From info at arin.net Wed Oct 26 17:13:03 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:13:03 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM Message-ID: <58111C5F.7060206@arin.net> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM to Last Call: The AC provided the following statement to the community: 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. During the Public Policy Meeting at ARIN 38 in Dallas, a concern was raised regarding the inclusion of comments on the fee structure in the policy statement. To address this issue an editorial change has been made while sending the policy to Last Call, removing the following unnecessary text from the proposed section 6.5.9.2, "(both policy and fee structure) unless or until the board adopts a specific more favorable fee structure for community networks." Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. The full text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM 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. 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 info at arin.net Wed Oct 26 17:14:14 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:14:14 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Message-ID: <58111CA6.9030404@arin.net> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) to Last Call: The AC provided the following statement to the community: Recommended Draft Policy ARIN 2015-2 contributes to fair and impartial number resources administration by removing an impediment to the transfer of IPv4 numbering resources to other RIRs when business needs change. This recommended draft allows for an entity to transfer addresses within the first 12 months after receiving a 24 month supply via the transfer market. It is technically sound in that it balances removing limits on transfers of IPv4 numbering resources to other RIRs with safeguards related to common ownership and control of the source and recipient to reduce the likelihood of fraudulent transactions. There is strong community support for this recommended draft policy as written. Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. The full text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN 2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) AC's assessment of conformance with the Principles of Internet Number Resource Policy: Draft Policy ARIN 2015-2 contributes to fair and impartial number resources administration by removing an impediment to the transfer of IPv4 numbering resources to other RIRs when business needs change within the first 12 months of receipt of a 24 month supply of IP addresses by an entity via the transfer market. It is technically sound in that it balances removing limits on transfers of IPv4 numbering resources to other RIRs with safeguards related to ownership and control described in the draft policy to reduce the likelihood of fraudulent transactions. There was strong community support for this draft policy at the NANOG 66 PPC and ARIN 37, subject only to some suggested editorial changes which have now been implemented in the latest version. Problem Statement: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. Policy statement: Replace 8.4, bullet 3, to read: "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, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers." Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there. The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse. a. Timetable for implementation: Immediate b. Anything else: N/A From info at arin.net Wed Oct 26 17:14:57 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:14:57 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months Message-ID: <58111CD1.5070207@arin.net> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months to Last Call: The AC provided the following statement to the community: ARIN 2016-2: "Change timeframes for IPv4 requests to 24 months" contributes to fair and impartial number resource administration by standardizing time frames for requests throughout the NRPM. This will streamline procedures for all new requests. The proposal has received a favorable community response on PPML, and at ARIN38 it was well supported and did not generate any opposition. Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. The full text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.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 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 Wed Oct 26 17:16:52 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:16:52 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy Message-ID: <58111D44.10601@arin.net> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy to Last Call: The AC provided the following statement to the community: This proposal is technically sound, fair, and impartial in that it establishes a new set of qualifying criteria for 8.3 and 8.4 transfers applicable to all requests. It is strongly supported by the community. Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. The full text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.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 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 Wed Oct 26 17:17:54 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:17:54 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-4: Transfers for new entrants Message-ID: <58111D82.2040301@arin.net> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2016-4: Transfers for new entrants to Last Call: The AC provided the following statement to the community: This proposal is technically sound and enables fair and impartial number policy. There is support for this policy in the ARIN community as expressed at ARIN 38 and on PPML. There has been no opposition stated to 2016-4. At the ARIN AC meeting held on 10/21/2016, it was agreed that in the "Anything else" section of Recommended Draft Policy 2016-4 stating that 'The text in 4.2.2 ?for specified transfers, or three months otherwise? and the text in 4.3.3 ?for specified transfers, or 12 months otherwise? should be stricken if ARIN-prop-227 is adopted' should be followed by ARIN staff as an instruction from the AC, presuming that 2016-2 (which is what ARIN-prop-227 has become) continues to move forward after last call. Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. The full text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ARIN-2016-4: Transfers for new entrants AC assessment of conformance with the Principles of Internet Number Resource Policy: The proposal is technically sound and enables fair and impartial number policy by ensuring that new organizations have a mechanism to access at least a minimum amount of resources from the transfer market. The staff and legal review (as updated 8/19/2016) is non-controversial. There is support and no concerns have been raised by the community regarding the proposal on PPML or elsewhere. Problem Statement: New organizations without existing IPv4 space may not always be able to qualify for an initial allocation under NRPM 4.2, particularly if they are categorized as ISPs and subject to 4.2.2.1.1. Use of /24. Now that ARIN?s free pool is exhausted, 4.2.1.6. Immediate need states that ?These cases are exceptional?, but that is no longer correct. End user organizations requiring less a /24 of address space may also be unable to acquire space from their upstream ISP, and may instead need to receive a /24 from ARIN via transfer. Policy statement: Replace Section 4.2.2 with: 4.2.2. Initial allocation to ISPs ?All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN?s minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months for specified transfers, or three months otherwise. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. Replace Section 4.3.2 to read: 4.3.2 Minimum assignment ARIN?s minimum assignment for end-user organizations is a /24. End-user organizations without direct assignments or allocations from ARIN qualify for an initial assignment of ARIN?s minimum assignment size. Replace the first two sentences of Section 4.3.3. Utilization rate to read: Organizations may qualify for a larger initial allocation by providing appropriate details to verify their 24-month growth projection for specified transfers, or 12 months otherwise. Resulting new section 4.3.3 will be: Organizations may qualify for a larger initial allocation, by providing appropriate details to verify their 24-month growth projection for specified transfers, or 12 months otherwise. The basic criterion that must be met is a 50% utilization rate within one year. A greater utilization rate may be required based on individual network requirements. Comments: Timetable for implementation: Immediate Anything else The text in 4.2.2 ?for specified transfers, or three months otherwise? and the text in 4.3.3 ?for specified transfers, or 12 months otherwise? should be stricken if ARIN-prop-227 is adopted. From info at arin.net Wed Oct 26 17:18:39 2016 From: info at arin.net (ARIN) Date: Wed, 26 Oct 2016 17:18:39 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy Message-ID: <58111DAF.9070706@arin.net> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy to Last Call: The AC provided the following statement to the community: This proposal is technically sound and enables fair and impartial number policy by ensuring that the number resources are used in accordance with the terms under which they were granted. There is significant support for this change within the Internet community. Re: Merge into 2016-5. The new text "Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer." should be added to the revised 2016-5 sections 8.3 & 8.4 "Conditions on source of the transfer:?. Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. The full text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy AC assessment of conformance with the Principles of Internet Number Resource Policy: This proposal enables fair and impartial number resource administration by ensuring that IPv4 resources, which are specially designated for critical infrastructure and IPv6 transition, are readily available for many years into the future. This is done by ensuring the resources remain in their originally designated pool rather than being moved into the general IPv4 address pool via a transfer. This proposal is technically sound and is supported by the community. Problem Statement: Section 8 of the current NRPM does not distinguish between the transfer of blocks from addresses that have been reserved for specific uses and other addresses that can be transferred. In sections 4.4 and 4.10 there are specific address blocks set aside, based on the need for critical infrastructure and IPv6 transitions. Two issues arise if transfers of reserved address space occur under the current language of section 8. First, if transfers of 4.4 or 4.10 space occur under the current policy requirements set forth in sections 8.3 and 8.4, the recipients will be able to acquire space that was originally reserved for a specific purpose without ever providing evidence that they will be using the space for either critical infrastructure or IPv6 transition. Second, if we allow an allocation or assignment from the block reserved in section 4.10 to be transferred out of the region, it would complicate the single aggregate from which providers are being asked to allow in block sizes smaller than a /24. This policy would limit the transfer of addresses from reserved pools. Policy statement: Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:" Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer. Timetable for implementation: Immediate From owen at delong.com Wed Oct 26 19:36:23 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Oct 2016 16:36:23 -0700 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy In-Reply-To: <58111D44.10601@arin.net> References: <58111D44.10601@arin.net> Message-ID: Speaking strictly for myself and not in my role as a member of the AC.. I remain strongly opposed to this proposal. While it is further along in the process, I believe that 2016-3 represents a vastly superior alternative with a higher level of community support. Speaking as a member of the AC, but not for the AC, I believe it would be valuable to the AC to get significant community feedback as to any preference between the two proposals. Owen > On Oct 26, 2016, at 14:16 , ARIN wrote: > > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy to Last Call: > > The AC provided the following statement to the community: > > This proposal is technically sound, fair, and impartial in that it establishes a new set of qualifying criteria for 8.3 and 8.4 transfers applicable to all requests. It is strongly supported by the community. > > Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.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 > > 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. > _______________________________________________ > 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. From Daniel_Alexander at comcast.com Thu Oct 27 06:46:11 2016 From: Daniel_Alexander at comcast.com (Alexander, Daniel) Date: Thu, 27 Oct 2016 10:46:11 +0000 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy In-Reply-To: References: <58111D44.10601@arin.net> Message-ID: Owen, It would be helpful to clarify why you feel one is a superior alternative to another beyond just stating so. Unless my PPML searches are incorrect, the numbers don't support your assertion that 2016-3 has a higher level of community support. 2016-3 had four people post to PPML with one in favor and one against. The one in favor being you. The PPM show of hands in Dallas, of 122 participants there were 27 for and one against the question to continue work on the draft. 2016-5 had eight people post to PPML with two in favor and one against. The one against being you. The PPM show of hands in Dallas, of 123 participants there were 33 in favor and 6 against this proposal moving forward. I encourage everyone to help the AC with comments to consider during this last call period. Thanks, -Dan On 10/27/16, 1:36 AM, "arin-ppml-bounces at arin.net on behalf of Owen DeLong" wrote: >Speaking strictly for myself and not in my role as a member of the AC.. > >I remain strongly opposed to this proposal. While it is further along in >the process, I believe that 2016-3 represents a vastly superior >alternative with a higher level of community support. > >Speaking as a member of the AC, but not for the AC, I believe it would be >valuable to the AC to get significant community feedback as to any >preference between the two proposals. > >Owen > >> On Oct 26, 2016, at 14:16 , ARIN wrote: >> >> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to >>send Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion >>Transfer Policy to Last Call: >> >> The AC provided the following statement to the community: >> >> This proposal is technically sound, fair, and impartial in that it >>establishes a new set of qualifying criteria for 8.3 and 8.4 transfers >>applicable to all requests. It is strongly supported by the community. >> >> Feedback is encouraged during the Last Call period. All comments should >>be provided to the Public Policy Mailing List. This Last Call will >>expire on 9 November 2016. After Last Call, the AC will conduct their >>Last Call review. >> >> The full text is below and available at: >> https://www.arin.net/policy/proposals/ >> >> The ARIN Policy Development Process is available at: >> https://www.arin.net/policy/pdp.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 >> >> 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. >> _______________________________________________ >> 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. > >_______________________________________________ >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. From owen at delong.com Thu Oct 27 12:12:54 2016 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Oct 2016 09:12:54 -0700 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy In-Reply-To: References: <58111D44.10601@arin.net> Message-ID: <400823F1-51E6-49EF-9BA2-249DB6D7354D@delong.com> I?ve now received both on and off-list requests to clarify my sustained opposition to 2016-5. All of the reasons stated in my original email on this subject remain: > I am opposed to this policy proposal. > > Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process. > > The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered. > > If we want to change IPv4 policy, then let?s change IPv4 policy in section 4. > > If we want to change transfer policy for all resources, we can do that cleanly in section 8. > > While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse. > It?s already been identified that this policy, absent creative staff interpretation (which staff conveniently said they would do) would have negative impact on TPIA networks. It?s unclear what impact this proposal would have on those which currently qualify for MDN. As much as people like to complain about the complexity in section 4, much of it has been put there for good reason and I do not think we should discard it so lightly without regard to the full ramifications. Owen From narten at us.ibm.com Fri Oct 28 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 28 Oct 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201610280453.u9S4r4fu019805@rotala.raleigh.ibm.com> Total of 14 messages in the last 7 days. script run at: Fri Oct 28 00:53:03 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 57.14% | 8 | 48.75% | 78796 | info at arin.net 14.29% | 2 | 13.55% | 21900 | owen at delong.com 7.14% | 1 | 14.69% | 23744 | jcurran at arin.net 7.14% | 1 | 11.11% | 17950 | daniel_alexander at comcast.com 7.14% | 1 | 6.60% | 10671 | alison.wood at oregon.gov 7.14% | 1 | 5.30% | 8561 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 14 |100.00% | 161622 | Total From rjletts at uw.edu Mon Oct 31 11:59:18 2016 From: rjletts at uw.edu (Richard J. Letts) Date: Mon, 31 Oct 2016 15:59:18 +0000 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy In-Reply-To: <58111D44.10601@arin.net> References: <58111D44.10601@arin.net> Message-ID: Following Owen's opposition to this I decided to have a look. This is probably not relevant to many of my users so I'd not looked in detail at this. I'm going to note that the NRPM is improperly called the Number Policy Resource Manual on the first line of the problem statement, which makes me wonder how many other errors there are in the rest of the document, or how closely this has been read by others? I'm bothered by a proposal that has a problem statement "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. " And then goes on to to "Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM." If section 4 is not relevant, then modify that, and not section 8 8.2: What incentive do I have for doing this? i.e. transferring assets between entities. Ah! it allows though M&A for entities to accumulate more resources than they would otherwise be able to. And provides no enforcement for the return of resources. Hmmm... looks like a problem to me. The other sections then exclude resources acquired through M&A activities from evaluation. If I had looked at this previously I would have removed 'This restriction does not include M&A transfers.' From 8.3-8.5 So, I'm going to come down as opposed to this. Richard Letts > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Wednesday, October 26, 2016 2:17 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: > Post-IPv4-Free-Pool-Depletion Transfer Policy > > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send > Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion > Transfer Policy to Last Call: > > The AC provided the following statement to the community: > > This proposal is technically sound, fair, and impartial in that it establishes a > new set of qualifying criteria for 8.3 and 8.4 transfers applicable to all > requests. It is strongly supported by the community. > > Feedback is encouraged during the Last Call period. All comments should be > provided to the Public Policy Mailing List. This Last Call will expire on 9 > November 2016. After Last Call, the AC will conduct their Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.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 > > 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. > _______________________________________________ > 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. From SRyerse at eclipse-networks.com Mon Oct 31 15:49:12 2016 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 31 Oct 2016 19:49:12 +0000 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy In-Reply-To: References: <58111D44.10601@arin.net> Message-ID: With all due respect, we have been at runout for about a year. There are lots of Legacy blocks being transferred from a willing seller to a willing buyer where an RSA gets signed as part of the process. Money changes hands in these transactions and ARIN gets a fee as well. Why do we need to try and stop or slow down transfers that go thru proper ARIN channels? Why can't we just make it reasonably easy for the market to take care of Needs and let ARIN process and manage the resources in the database going forward. Everyone wins in this scenario. The time will come where the readily available supply of Legacy blocks will be mostly used up and then all of these policies will make it even harder to get resources. I think the time has come that ARIN should be trying to make it easier to get resources. With runout I see no real harm in making transfers easier and not harder. +1 Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392.0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Richard J. Letts Sent: Monday, October 31, 2016 11:59 AM To: ARIN ; arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy Following Owen's opposition to this I decided to have a look. This is probably not relevant to many of my users so I'd not looked in detail at this. I'm going to note that the NRPM is improperly called the Number Policy Resource Manual on the first line of the problem statement, which makes me wonder how many other errors there are in the rest of the document, or how closely this has been read by others? I'm bothered by a proposal that has a problem statement "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. " And then goes on to to "Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM." If section 4 is not relevant, then modify that, and not section 8 8.2: What incentive do I have for doing this? i.e. transferring assets between entities. Ah! it allows though M&A for entities to accumulate more resources than they would otherwise be able to. And provides no enforcement for the return of resources. Hmmm... looks like a problem to me. The other sections then exclude resources acquired through M&A activities from evaluation. If I had looked at this previously I would have removed 'This restriction does not include M&A transfers.' From 8.3-8.5 So, I'm going to come down as opposed to this. Richard Letts > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of ARIN > Sent: Wednesday, October 26, 2016 2:17 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: > Post-IPv4-Free-Pool-Depletion Transfer Policy > > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to > send Recommended Draft Policy ARIN-2016-5: > Post-IPv4-Free-Pool-Depletion Transfer Policy to Last Call: > > The AC provided the following statement to the community: > > This proposal is technically sound, fair, and impartial in that it > establishes a new set of qualifying criteria for 8.3 and 8.4 transfers > applicable to all requests. It is strongly supported by the community. > > Feedback is encouraged during the Last Call period. All comments > should be provided to the Public Policy Mailing List. This Last Call > will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.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 > > 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. > _______________________________________________ > 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. _______________________________________________ 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.