From narten at us.ibm.com Fri May 1 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 01 May 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201505010453.t414r38B016393@rotala.raleigh.ibm.com> Total of 6 messages in the last 7 days. script run at: Fri May 1 00:53:03 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 66.67% | 4 | 65.54% | 39225 | info at arin.net 16.67% | 1 | 23.01% | 13773 | michael at linuxmagic.com 16.67% | 1 | 11.45% | 6851 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 59849 | Total From info at arin.net Fri May 1 18:01:05 2015 From: info at arin.net (ARIN) Date: Fri, 01 May 2015 18:01:05 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - April 2015 In-Reply-To: <553E5E55.1050901@arin.net> References: <553E5E55.1050901@arin.net> Message-ID: <5543F7A1.7010301@arin.net> > The AC abandoned 2014-1, 2014-14 and 2014-22. Anyone dissatisfied with > these decisions 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 minutes from the ARIN Advisory Council's 19 February meeting have been published: https://www.arin.net/about_us/ac/ac2015_0415.html The petition deadline is 8 May 2015. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 4/27/15 12:05 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) met on 15 April 2015. > > The AC moved the following to last call (to be posted separately to last > call): > > Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS > Text > Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size > per Section 4.4 > > The AC abandoned the following: > > Recommended Draft Policy ARIN-2014-1: Out of Region Use > Recommended Draft Policy ARIN-2014-14: Removing Needs Test from Small > IPv4 Transfers > Recommended Draft Policy ARIN-2014-22: Removal of Minimum in Section > 4.10 > > The AC provided the following statements: > > Regarding ARIN-2014-1: Out of Region Use: > > "After taking into careful consideration feedback from the ARIN > community, both on PPML and at ARIN 35, the AC voted to abandon 2014-1. > > The AC's consensus is that more work is needed in clarifying and > resolving issues in this area and that a new proposal is more likely to > yield favorable results than continued efforts to tweak the existing > proposal, which has morphed considerably from the original author's > intent. To that end, there are AC members currently working to craft a > new proposal in this problem space." > > Regarding ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers: > > "In its meeting on April 15th, 2015 following ARIN35, the ARIN advisory > council voted to abandon Draft Policy 2014-14 due to lack of support in > the community, as expressed in the Public Policy Meeting and on PPML." > > Regarding ARIN-2014-22: Removal of Minimum in Section 4.10: > > "The ARIN Advisory Council, based on input from the community, has voted > to abandon ARIN 2014-22 Removal of Minimum in Section 4.10. > > The primary goal of Section 4.10 is to provide small blocks of IPv4 > space to new entrants for IPv6. The removal of the minimum would have > significantly reduced the number of blocks available. > > While blocks smaller than /24 are not widely routable today, the > Advisory Council believes the change would be premature. > > As a first step to address routability concerns, the AC also recommends > that ARIN take additional measures to increase awareness of the specific > /10 netblock reserved for assignments under 4.10." > > == > > The AC is continuing to work on: > > Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial > End-User Assignments > > The AC found the revisions to the ARIN NRPM Section 5 (as posted to PPML > on 24 February 2015) to be editorial in nature and recommended they be > adopted by the ARIN Board of Trustees. > > The AC abandoned 2014-1, 2014-14 and 2014-22. Anyone dissatisfied with > these decisions may initiate a petition. The deadline to begin a > petition will be five business days after the AC's draft meeting minutes > are published. For more information on starting and participating in > petitions, see PDP Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) From rudi.daniel at gmail.com Fri May 1 19:00:23 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Fri, 1 May 2015 19:00:23 -0400 Subject: [arin-ppml] ARIN- 2014-21 Message-ID: I support this policy as AC recommends. RD On May 1, 2015 6:01 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. LAST CALL: Recommended Draft Policy ARIN-2014-21: > Modification to CI Pool Size per Section 4.4 (ARIN) > 2. Re: LAST CALL: Recommended Draft Policy ARIN-2014-6: Remove > Operational Reverse DNS Text (Michael Peddemors) > 3. Re: LAST CALL: Recommended Draft Policy ARIN-2014-21: > Modification to CI Pool Size per Section 4.4 (ARIN) > 4. Weekly posting summary for ppml at arin.net (Thomas Narten) > 5. Re: Advisory Council Meeting Results - April 2015 (ARIN) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Apr 2015 12:06:10 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-21: > Modification to CI Pool Size per Section 4.4 > Message-ID: <553E5E72.6060605 at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > The ARIN Advisory Council (AC) met on 15 April 2015 and decided to > send the following to last call: > > Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size > per Section 4.4 > > 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 11 May 2015. After last call the AC will conduct their > last call review. > > The draft policy 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-2014-21 > Modification to CI Pool Size per Section 4.4 > > Date: 25 November 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal enables fair and impartial number resource administration > by ensuring IPv4 resources are available for critical infrastructure and > Internet Exchanges in particular after IPv4 resources are no longer > readily available from the ARIN free pool. This benefits more than just > the individual organizations receiving these resources; it benefits the > entire Internet Community by contributing to the stability and > scalability of the Internet as a whole. This proposal is technically > sound and is supported by the community. > > Problem Statement: > > At the time that this section of policy was written, IXP growth in North > America was stagnant. Efforts of late have increased significantly > within the IXP standards and other communities to improve critical > infrastructure in North America. This effort is paying dividends and we > project that a /16 will not be enough to continue to improve global > interconnect conditions and support needed IXP CI infrastructure. > > Policy statement: > > Change to text in section 4.4 Micro Allocations: > > Current text: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > > Proposed text to replace current text entirely: > > ARIN will place an equivalent of a /15 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. > > Timetable for implementation: Immediate > > ##### > > ARIN STAFF ASSESSMENT > > Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 > Date of Assessment: 14 January 2015 > > 1. Summary (Staff Understanding) > > This policy changes one section of existing NRPM policy 4.4 to extend > the current reservation size for critical infrastructure and exchange > points from a /16 equivalent to a /15 equivalent. > > > 2. Comments > > A. ARIN Staff Comments > > ??? For informational purposes: > ??? A total of 35 /24s have been issued from the reserved /16 equivalent > for CI and IXPs since the policy was amended and implemented on 20 March > 2013, leaving 221 /24s available in this reserved block. > > ??? There are currently 381 free /24s remaining in the two /8 ranges > used for CI and IXP micro-allocations. > > ??? This policy could be implemented as written. > > > B. ARIN General Counsel - Legal Assessment > > This proposal does not create any material legal issue. > > 3. Resource Impact > > This policy would have minimal resource impact from an implementation > aspect. It is estimated that implementation would occur within 3 months > after ratification by the ARIN Board of Trustees. The following would be > needed in order to implement: > ?? Updated guidelines and internal procedures > ?? Staff training > > 4. Proposal/Draft Policy Text Assessed > Draft Policy ARIN-2014-21???Modification to CI Pool Size per Section 4.4 > Date: 25 November 2014 > Problem Statement: > At the time that this section of policy was written, IXP growth in North > America was stagnant. Efforts of late have increased significantly > within the IXP standards and other communities to improve critical > infrastructure in North America. This effort is paying dividends and we > project that a /16 will not be enough to continue to improve global > interconnect conditions and support needed IXP CI infrastructure. > Policy statement: > Change to text in section 4.4 Micro Allocations: > Current text: > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > Proposed text to replace current text entirely: > ARIN will place an equivalent of a /15 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. > > > ------------------------------ > > Message: 2 > Date: Mon, 27 Apr 2015 09:42:24 -0700 > From: Michael Peddemors > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy > ARIN-2014-6: Remove Operational Reverse DNS Text > Message-ID: <553E66F0.9040000 at linuxmagic.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Vote against.. > > In my opinion, the granting of a public IPv4 (or IPv6) address space > SHOULD come alone with some responsibility, including > 'rwhois/SWIP/routing/rDNS obligations'. > > I would rather have more work done by the community at large to reach > consensus on those things, even IF ARIN has little enforcement mandate > at this time, we should be able to reference it in discussions. > > I suggest abandoning "Recommended Draft Policy ARIN-2014-6" and work on > better language. > > On 15-04-27 09:05 AM, ARIN wrote: > > The ARIN Advisory Council (AC) met on 15 April 2015 and decided to > > send the following to last call: > > > > Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS > > Text > > > > 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 11 May 2015. After last call the AC will conduct their > > last call review. > > > > The draft policy 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-2014-6 > > Remove Operational Reverse DNS Text (was: Remove 7.1) > > > > Date: 21 January 2014 > > > > AC's assessment of conformance with the Principles of Internet Number > > Resource Policy: > > > > 2014-6 enables fair and impartial number resource administration by > > removing technical statements that are not related to number policy from > > the NRPM. It is technically sound to remove operational practice from > > the NRPM; indeed this act serves as a forcing function for a best > > practices document that is both more detailed and more approachable than > > the policy statement that was removed. Discussion of the previous > > revision of 2014-6 centered around "why are you fixing this for IPv4 and > > not IPv6", and the most recent changes reflect that community feedback. > > There has not been notable opposition to the notion of removing > > operational language from the NRPM. > > > > Problem Statement: > > > > 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do > > so because it only addresses in-addr.arpa (missing equally important > > rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary > > decision made by ARIN technical staff. We should remove this text from > > policy, as it represents operational practice rather than ARIN number > > policy. > > > > In feedback received at public policy meetings and on the PPML mailing > > list, the Community expressed a desire for IPv4 and IPv6 policy on > > reverse DNS to be congruent (that is to say, it makes no sense to remove > > 7.1 without addressing 6.5.6 which is similarly operationally > > prescriptive) and bring this proposal forward again. > > > > Policy statement: > > > > Remove 7.1 > > > > Remove 6.5.6 > > > > Comments: > > > > a.Timetable for implementation: Immediate > > > > b.Anything else: > > 7.1. Maintaining IN-ADDRs > > > > All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses > > from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain > > records for their respective customers. For blocks smaller than /16, and > > for the segment of larger blocks smaller than /16, ARIN can maintain > > IN-ADDRs. > > > > 6.5.6. Reverse lookup > > > > When an RIR delegates IPv6 address space to an organization, it also > > delegates the responsibility to manage the reverse lookup zone that > > corresponds to the allocated IPv6 address space. Each organization > > should properly manage its reverse lookup zone. When making an address > > assignment, the organization must delegate to an assignee organization, > > upon request, the responsibility to manage the reverse lookup zone that > > corresponds to the assigned address. > > > > ##### > > > > ARIN STAFF & LEGAL ASSESSMENT > > > > Draft Policy ARIN-2014-6 > > Remove Operational Reverse DNS Text > > > > Date of Assessment: March 17, 2015 > > > > 1. Summary (Staff Understanding) > > This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS > > language from the NRPM. > > > > 2. Comments > > A. ARIN Staff Comments > > This change to NRPM will not change the DNS service that ARIN performs. > > This proposal can be implemented as written. > > > > ARIN registration services staff occasionally receives a telephone or > > email inquiry asking how reverse DNS services can be set up for a > > company. In the cases the company is a downstream customer of an ISP who > > has received a direct allocation from ARIN, staff explains this service > > can be set up for them by their service provider. On rare occasion, the > > company presses for a reference that states this is done by their ISP, > > and not ARIN. In those cases staff will refer them to the language > > currently in the NRPM. > > > > In the case the language is removed from NRPM, ARIN staff will create a > > resource for the ARIN public website that describes how ARIN's Reverse > > DNS services are provided; including who is able to establish Reverse > > DNS service for different types of registration records. > > > > B. ARIN General Counsel ??? Legal Assessment > > The policy does not create legal concerns. > > > > 3. Resource Impact > > This policy would have minimal impact from an implementation standpoint. > > It is estimated implementation would occur within 3 months after > > ratification by the ARIN Board of Trustees. The following tasks will be > > completed for implementation: > > Versioned change to NRPM > > Updated guidelines on ARIN website describing reverse DNS services (to > > act as general information resource and serve as new reference point for > > situation described in staff comments). > > Staff training > > > > 4. Proposal / Draft Policy Text Assessed > > > > Draft Policy ARIN-2014-6 > > Remove Operational Reverse DNS Text (was: Remove 7.1) > > > > Date: 21 January 2015 > > > > Problem Statement: > > > > 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do > > so because it only addresses in-addr.arpa (missing equally important > > rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary > > decision made by ARIN technical staff. We should remove this text from > > policy, as it represents operational practice rather than ARIN number > > policy. > > > > In feedback received at public policy meetings and on the PPML mailing > > list, the Community expressed a desire for IPv4 and IPv6 policy on > > reverse DNS to be congruent (that is to say, it makes no sense to remove > > 7.1 without addressing 6.5.6 which is similarly operationally > > prescriptive) and bring this proposal forward again. > > > > Policy statement: > > > > Remove 7.1 > > > > Remove 6.5.6 > > > > Comments: > > > > a.Timetable for implementation: Immediate > > > > b.Anything else: > > > > 7.1. Maintaining IN-ADDRs > > > > All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses > > from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain > > records for their respective customers. For blocks smaller than /16, and > > for the segment of larger blocks smaller than /16, ARIN can maintain > > IN-ADDRs. > > > > 6.5.6. Reverse lookup > > > > When an RIR delegates IPv6 address space to an organization, it also > > delegates the responsibility to manage the reverse lookup zone that > > corresponds to the allocated IPv6 address space. Each organization > > should properly manage its reverse lookup zone. When making an address > > assignment, the organization must delegate to an assignee organization, > > upon request, the responsibility to manage the reverse lookup zone that > > corresponds to the assigned address. > > _______________________________________________ > > 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. > > > ------------------------------ > > Message: 3 > Date: Mon, 27 Apr 2015 15:14:40 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy > ARIN-2014-21: Modification to CI Pool Size per Section 4.4 > Message-ID: <553E8AA0.3080001 at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > The ARIN Advisory Council provided an updated assessment of 2014-21: > > "This proposal is technically sound, enables fair and impartial number > resource administration by ensuring IPv4 resources are available for > critical infrastructure and Internet exchanges in particular after IPv4 > resources are no longer readily available from the ARIN free pool. This > benefits more than just the individual organizations receiving these > resources; it benefits the entire Internet community by contributing to > the stability and scalability of the Internet as a whole. Although a > portion of the community believes the current reservation is sufficient > and that expanding it will unnecessarily impact those that would have > otherwise received the resources, the majority of the community polled > concluded the reservation is justified and supports the proposal." > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > On 4/27/15 12:06 PM, ARIN wrote: > > The ARIN Advisory Council (AC) met on 15 April 2015 and decided to > > send the following to last call: > > > > Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size > > per Section 4.4 > > > > 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 11 May 2015. After last call the AC will conduct their > > last call review. > > > > The draft policy 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-2014-21 > > Modification to CI Pool Size per Section 4.4 > > > > Date: 25 November 2014 > > > > AC's assessment of conformance with the Principles of Internet Number > > Resource Policy: > > > > This proposal enables fair and impartial number resource administration > > by ensuring IPv4 resources are available for critical infrastructure and > > Internet Exchanges in particular after IPv4 resources are no longer > > readily available from the ARIN free pool. This benefits more than just > > the individual organizations receiving these resources; it benefits the > > entire Internet Community by contributing to the stability and > > scalability of the Internet as a whole. This proposal is technically > > sound and is supported by the community. > > > > Problem Statement: > > > > At the time that this section of policy was written, IXP growth in North > > America was stagnant. Efforts of late have increased significantly > > within the IXP standards and other communities to improve critical > > infrastructure in North America. This effort is paying dividends and we > > project that a /16 will not be enough to continue to improve global > > interconnect conditions and support needed IXP CI infrastructure. > > > > Policy statement: > > > > Change to text in section 4.4 Micro Allocations: > > > > Current text: > > > > ARIN will place an equivalent of a /16 of IPv4 address space in a > > reserve for Critical Infrastructure, as defined in section 4.4. If at > > the end of the policy term there is unused address space remaining in > > this pool, ARIN staff is authorized to utilize this space in a manner > > consistent with community expectations. > > > > Proposed text to replace current text entirely: > > > > ARIN will place an equivalent of a /15 of IPv4 address space in a > > reserve for Critical Infrastructure, as defined in section 4.4. > > > > Timetable for implementation: Immediate > > > > ##### > > > > ARIN STAFF ASSESSMENT > > > > Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 > > Date of Assessment: 14 January 2015 > > > > 1. Summary (Staff Understanding) > > > > This policy changes one section of existing NRPM policy 4.4 to extend > > the current reservation size for critical infrastructure and exchange > > points from a /16 equivalent to a /15 equivalent. > > > > > > 2. Comments > > > > A. ARIN Staff Comments > > > > ??? For informational purposes: > > ??? A total of 35 /24s have been issued from the reserved /16 equivalent > > for CI and IXPs since the policy was amended and implemented on 20 March > > 2013, leaving 221 /24s available in this reserved block. > > > > ??? There are currently 381 free /24s remaining in the two /8 ranges > > used for CI and IXP micro-allocations. > > > > ??? This policy could be implemented as written. > > > > > > B. ARIN General Counsel - Legal Assessment > > > > This proposal does not create any material legal issue. > > > > 3. Resource Impact > > > > This policy would have minimal resource impact from an implementation > > aspect. It is estimated that implementation would occur within 3 months > > after ratification by the ARIN Board of Trustees. The following would be > > needed in order to implement: > > ?? Updated guidelines and internal procedures > > ?? Staff training > > > > 4. Proposal/Draft Policy Text Assessed > > Draft Policy ARIN-2014-21???Modification to CI Pool Size per Section 4.4 > > Date: 25 November 2014 > > Problem Statement: > > At the time that this section of policy was written, IXP growth in North > > America was stagnant. Efforts of late have increased significantly > > within the IXP standards and other communities to improve critical > > infrastructure in North America. This effort is paying dividends and we > > project that a /16 will not be enough to continue to improve global > > interconnect conditions and support needed IXP CI infrastructure. > > Policy statement: > > Change to text in section 4.4 Micro Allocations: > > Current text: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > > reserve for Critical Infrastructure, as defined in section 4.4. If at > > the end of the policy term there is unused address space remaining in > > this pool, ARIN staff is authorized to utilize this space in a manner > > consistent with community expectations. > > Proposed text to replace current text entirely: > > ARIN will place an equivalent of a /15 of IPv4 address space in a > > reserve for Critical Infrastructure, as defined in section 4.4. > > > > ------------------------------ > > Message: 4 > Date: Fri, 01 May 2015 00:53:03 -0400 > From: Thomas Narten > To: arin-ppml at arin.net > Subject: [arin-ppml] Weekly posting summary for ppml at arin.net > Message-ID: <201505010453.t414r38B016393 at rotala.raleigh.ibm.com> > Content-Type: text/plain; charset=us-ascii > > Total of 6 messages in the last 7 days. > > script run at: Fri May 1 00:53:03 EDT 2015 > > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 66.67% | 4 | 65.54% | 39225 | info at arin.net > 16.67% | 1 | 23.01% | 13773 | michael at linuxmagic.com > 16.67% | 1 | 11.45% | 6851 | narten at us.ibm.com > --------+------+--------+----------+------------------------ > 100.00% | 6 |100.00% | 59849 | Total > > > > ------------------------------ > > Message: 5 > Date: Fri, 01 May 2015 18:01:05 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Advisory Council Meeting Results - April 2015 > Message-ID: <5543F7A1.7010301 at arin.net> > Content-Type: text/plain; charset=windows-1252; format=flowed > > > The AC abandoned 2014-1, 2014-14 and 2014-22. Anyone dissatisfied with > > these decisions 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 minutes from the ARIN Advisory Council's 19 February meeting have > been published: > https://www.arin.net/about_us/ac/ac2015_0415.html > > The petition deadline is 8 May 2015. > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > On 4/27/15 12:05 PM, ARIN wrote: > > In accordance with the ARIN Policy Development Process (PDP), the ARIN > > Advisory Council (AC) met on 15 April 2015. > > > > The AC moved the following to last call (to be posted separately to last > > call): > > > > Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS > > Text > > Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size > > per Section 4.4 > > > > The AC abandoned the following: > > > > Recommended Draft Policy ARIN-2014-1: Out of Region Use > > Recommended Draft Policy ARIN-2014-14: Removing Needs Test from Small > > IPv4 Transfers > > Recommended Draft Policy ARIN-2014-22: Removal of Minimum in Section > > 4.10 > > > > The AC provided the following statements: > > > > Regarding ARIN-2014-1: Out of Region Use: > > > > "After taking into careful consideration feedback from the ARIN > > community, both on PPML and at ARIN 35, the AC voted to abandon 2014-1. > > > > The AC's consensus is that more work is needed in clarifying and > > resolving issues in this area and that a new proposal is more likely to > > yield favorable results than continued efforts to tweak the existing > > proposal, which has morphed considerably from the original author's > > intent. To that end, there are AC members currently working to craft a > > new proposal in this problem space." > > > > Regarding ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers: > > > > "In its meeting on April 15th, 2015 following ARIN35, the ARIN advisory > > council voted to abandon Draft Policy 2014-14 due to lack of support in > > the community, as expressed in the Public Policy Meeting and on PPML." > > > > Regarding ARIN-2014-22: Removal of Minimum in Section 4.10: > > > > "The ARIN Advisory Council, based on input from the community, has voted > > to abandon ARIN 2014-22 Removal of Minimum in Section 4.10. > > > > The primary goal of Section 4.10 is to provide small blocks of IPv4 > > space to new entrants for IPv6. The removal of the minimum would have > > significantly reduced the number of blocks available. > > > > While blocks smaller than /24 are not widely routable today, the > > Advisory Council believes the change would be premature. > > > > As a first step to address routability concerns, the AC also recommends > > that ARIN take additional measures to increase awareness of the specific > > /10 netblock reserved for assignments under 4.10." > > > > == > > > > The AC is continuing to work on: > > > > Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial > > End-User Assignments > > > > The AC found the revisions to the ARIN NRPM Section 5 (as posted to PPML > > on 24 February 2015) to be editorial in nature and recommended they be > > adopted by the ARIN Board of Trustees. > > > > The AC abandoned 2014-1, 2014-14 and 2014-22. Anyone dissatisfied with > > these decisions may initiate a petition. The deadline to begin a > > petition will be five business days after the AC's draft meeting minutes > > are published. For more information on starting and participating in > > petitions, see PDP Petitions at: > > https://www.arin.net/policy/pdp_petitions.html > > > > Draft Policy and Proposal texts are available at: > > https://www.arin.net/policy/proposals/index.html > > > > The ARIN Policy Development Process can be found at: > > https://www.arin.net/policy/pdp.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 119, Issue 1 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Fri May 1 20:46:18 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Fri, 1 May 2015 20:46:18 -0400 Subject: [arin-ppml] ARIN- 2014-21 In-Reply-To: <0E096662-81D3-4E19-A2FB-EE609510BE5D@delong.com> References: <0E096662-81D3-4E19-A2FB-EE609510BE5D@delong.com> Message-ID: Aha...CI pool. I support 2014-21 ...thanks Owen. RD On May 1, 2015 8:37 PM, "Owen DeLong" wrote: > Which one? You included a digest that covers 3 of them. > > Owen > > On May 1, 2015, at 16:00 , Rudolph Daniel wrote: > > I support this policy as AC recommends. > RD > On May 1, 2015 6:01 PM, wrote: > >> Send ARIN-PPML mailing list submissions to >> arin-ppml at arin.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.arin.net/mailman/listinfo/arin-ppml >> or, via email, send a message with subject or body 'help' to >> arin-ppml-request at arin.net >> >> You can reach the person managing the list at >> arin-ppml-owner at arin.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of ARIN-PPML digest..." >> >> >> Today's Topics: >> >> 1. LAST CALL: Recommended Draft Policy ARIN-2014-21: >> Modification to CI Pool Size per Section 4.4 (ARIN) >> 2. Re: LAST CALL: Recommended Draft Policy ARIN-2014-6: Remove >> Operational Reverse DNS Text (Michael Peddemors) >> 3. Re: LAST CALL: Recommended Draft Policy ARIN-2014-21: >> Modification to CI Pool Size per Section 4.4 (ARIN) >> 4. Weekly posting summary for ppml at arin.net (Thomas Narten) >> 5. Re: Advisory Council Meeting Results - April 2015 (ARIN) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 27 Apr 2015 12:06:10 -0400 >> From: ARIN >> To: arin-ppml at arin.net >> Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-21: >> Modification to CI Pool Size per Section 4.4 >> Message-ID: <553E5E72.6060605 at arin.net> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> The ARIN Advisory Council (AC) met on 15 April 2015 and decided to >> send the following to last call: >> >> Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size >> per Section 4.4 >> >> 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 11 May 2015. After last call the AC will conduct their >> last call review. >> >> The draft policy 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-2014-21 >> Modification to CI Pool Size per Section 4.4 >> >> Date: 25 November 2014 >> >> AC's assessment of conformance with the Principles of Internet Number >> Resource Policy: >> >> This proposal enables fair and impartial number resource administration >> by ensuring IPv4 resources are available for critical infrastructure and >> Internet Exchanges in particular after IPv4 resources are no longer >> readily available from the ARIN free pool. This benefits more than just >> the individual organizations receiving these resources; it benefits the >> entire Internet Community by contributing to the stability and >> scalability of the Internet as a whole. This proposal is technically >> sound and is supported by the community. >> >> Problem Statement: >> >> At the time that this section of policy was written, IXP growth in North >> America was stagnant. Efforts of late have increased significantly >> within the IXP standards and other communities to improve critical >> infrastructure in North America. This effort is paying dividends and we >> project that a /16 will not be enough to continue to improve global >> interconnect conditions and support needed IXP CI infrastructure. >> >> Policy statement: >> >> Change to text in section 4.4 Micro Allocations: >> >> Current text: >> >> ARIN will place an equivalent of a /16 of IPv4 address space in a >> reserve for Critical Infrastructure, as defined in section 4.4. If at >> the end of the policy term there is unused address space remaining in >> this pool, ARIN staff is authorized to utilize this space in a manner >> consistent with community expectations. >> >> Proposed text to replace current text entirely: >> >> ARIN will place an equivalent of a /15 of IPv4 address space in a >> reserve for Critical Infrastructure, as defined in section 4.4. >> >> Timetable for implementation: Immediate >> >> ##### >> >> ARIN STAFF ASSESSMENT >> >> Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 >> Date of Assessment: 14 January 2015 >> >> 1. Summary (Staff Understanding) >> >> This policy changes one section of existing NRPM policy 4.4 to extend >> the current reservation size for critical infrastructure and exchange >> points from a /16 equivalent to a /15 equivalent. >> >> >> 2. Comments >> >> A. ARIN Staff Comments >> >> ??? For informational purposes: >> ??? A total of 35 /24s have been issued from the reserved /16 equivalent >> for CI and IXPs since the policy was amended and implemented on 20 March >> 2013, leaving 221 /24s available in this reserved block. >> >> ??? There are currently 381 free /24s remaining in the two /8 ranges >> used for CI and IXP micro-allocations. >> >> ??? This policy could be implemented as written. >> >> >> B. ARIN General Counsel - Legal Assessment >> >> This proposal does not create any material legal issue. >> >> 3. Resource Impact >> >> This policy would have minimal resource impact from an implementation >> aspect. It is estimated that implementation would occur within 3 months >> after ratification by the ARIN Board of Trustees. The following would be >> needed in order to implement: >> ?? Updated guidelines and internal procedures >> ?? Staff training >> >> 4. Proposal/Draft Policy Text Assessed >> Draft Policy ARIN-2014-21???Modification to CI Pool Size per Section 4.4 >> Date: 25 November 2014 >> Problem Statement: >> At the time that this section of policy was written, IXP growth in North >> America was stagnant. Efforts of late have increased significantly >> within the IXP standards and other communities to improve critical >> infrastructure in North America. This effort is paying dividends and we >> project that a /16 will not be enough to continue to improve global >> interconnect conditions and support needed IXP CI infrastructure. >> Policy statement: >> Change to text in section 4.4 Micro Allocations: >> Current text: >> ARIN will place an equivalent of a /16 of IPv4 address space in a >> reserve for Critical Infrastructure, as defined in section 4.4. If at >> the end of the policy term there is unused address space remaining in >> this pool, ARIN staff is authorized to utilize this space in a manner >> consistent with community expectations. >> Proposed text to replace current text entirely: >> ARIN will place an equivalent of a /15 of IPv4 address space in a >> reserve for Critical Infrastructure, as defined in section 4.4. >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 27 Apr 2015 09:42:24 -0700 >> From: Michael Peddemors >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy >> ARIN-2014-6: Remove Operational Reverse DNS Text >> Message-ID: <553E66F0.9040000 at linuxmagic.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Vote against.. >> >> In my opinion, the granting of a public IPv4 (or IPv6) address space >> SHOULD come alone with some responsibility, including >> 'rwhois/SWIP/routing/rDNS obligations'. >> >> I would rather have more work done by the community at large to reach >> consensus on those things, even IF ARIN has little enforcement mandate >> at this time, we should be able to reference it in discussions. >> >> I suggest abandoning "Recommended Draft Policy ARIN-2014-6" and work on >> better language. >> >> On 15-04-27 09:05 AM, ARIN wrote: >> > The ARIN Advisory Council (AC) met on 15 April 2015 and decided to >> > send the following to last call: >> > >> > Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS >> > Text >> > >> > 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 11 May 2015. After last call the AC will conduct their >> > last call review. >> > >> > The draft policy 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-2014-6 >> > Remove Operational Reverse DNS Text (was: Remove 7.1) >> > >> > Date: 21 January 2014 >> > >> > AC's assessment of conformance with the Principles of Internet Number >> > Resource Policy: >> > >> > 2014-6 enables fair and impartial number resource administration by >> > removing technical statements that are not related to number policy from >> > the NRPM. It is technically sound to remove operational practice from >> > the NRPM; indeed this act serves as a forcing function for a best >> > practices document that is both more detailed and more approachable than >> > the policy statement that was removed. Discussion of the previous >> > revision of 2014-6 centered around "why are you fixing this for IPv4 and >> > not IPv6", and the most recent changes reflect that community feedback. >> > There has not been notable opposition to the notion of removing >> > operational language from the NRPM. >> > >> > Problem Statement: >> > >> > 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do >> > so because it only addresses in-addr.arpa (missing equally important >> > rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary >> > decision made by ARIN technical staff. We should remove this text from >> > policy, as it represents operational practice rather than ARIN number >> > policy. >> > >> > In feedback received at public policy meetings and on the PPML mailing >> > list, the Community expressed a desire for IPv4 and IPv6 policy on >> > reverse DNS to be congruent (that is to say, it makes no sense to remove >> > 7.1 without addressing 6.5.6 which is similarly operationally >> > prescriptive) and bring this proposal forward again. >> > >> > Policy statement: >> > >> > Remove 7.1 >> > >> > Remove 6.5.6 >> > >> > Comments: >> > >> > a.Timetable for implementation: Immediate >> > >> > b.Anything else: >> > 7.1. Maintaining IN-ADDRs >> > >> > All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses >> > from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain >> > records for their respective customers. For blocks smaller than /16, and >> > for the segment of larger blocks smaller than /16, ARIN can maintain >> > IN-ADDRs. >> > >> > 6.5.6. Reverse lookup >> > >> > When an RIR delegates IPv6 address space to an organization, it also >> > delegates the responsibility to manage the reverse lookup zone that >> > corresponds to the allocated IPv6 address space. Each organization >> > should properly manage its reverse lookup zone. When making an address >> > assignment, the organization must delegate to an assignee organization, >> > upon request, the responsibility to manage the reverse lookup zone that >> > corresponds to the assigned address. >> > >> > ##### >> > >> > ARIN STAFF & LEGAL ASSESSMENT >> > >> > Draft Policy ARIN-2014-6 >> > Remove Operational Reverse DNS Text >> > >> > Date of Assessment: March 17, 2015 >> > >> > 1. Summary (Staff Understanding) >> > This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS >> > language from the NRPM. >> > >> > 2. Comments >> > A. ARIN Staff Comments >> > This change to NRPM will not change the DNS service that ARIN performs. >> > This proposal can be implemented as written. >> > >> > ARIN registration services staff occasionally receives a telephone or >> > email inquiry asking how reverse DNS services can be set up for a >> > company. In the cases the company is a downstream customer of an ISP who >> > has received a direct allocation from ARIN, staff explains this service >> > can be set up for them by their service provider. On rare occasion, the >> > company presses for a reference that states this is done by their ISP, >> > and not ARIN. In those cases staff will refer them to the language >> > currently in the NRPM. >> > >> > In the case the language is removed from NRPM, ARIN staff will create a >> > resource for the ARIN public website that describes how ARIN's Reverse >> > DNS services are provided; including who is able to establish Reverse >> > DNS service for different types of registration records. >> > >> > B. ARIN General Counsel ??? Legal Assessment >> > The policy does not create legal concerns. >> > >> > 3. Resource Impact >> > This policy would have minimal impact from an implementation standpoint. >> > It is estimated implementation would occur within 3 months after >> > ratification by the ARIN Board of Trustees. The following tasks will be >> > completed for implementation: >> > Versioned change to NRPM >> > Updated guidelines on ARIN website describing reverse DNS services (to >> > act as general information resource and serve as new reference point for >> > situation described in staff comments). >> > Staff training >> > >> > 4. Proposal / Draft Policy Text Assessed >> > >> > Draft Policy ARIN-2014-6 >> > Remove Operational Reverse DNS Text (was: Remove 7.1) >> > >> > Date: 21 January 2015 >> > >> > Problem Statement: >> > >> > 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do >> > so because it only addresses in-addr.arpa (missing equally important >> > rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary >> > decision made by ARIN technical staff. We should remove this text from >> > policy, as it represents operational practice rather than ARIN number >> > policy. >> > >> > In feedback received at public policy meetings and on the PPML mailing >> > list, the Community expressed a desire for IPv4 and IPv6 policy on >> > reverse DNS to be congruent (that is to say, it makes no sense to remove >> > 7.1 without addressing 6.5.6 which is similarly operationally >> > prescriptive) and bring this proposal forward again. >> > >> > Policy statement: >> > >> > Remove 7.1 >> > >> > Remove 6.5.6 >> > >> > Comments: >> > >> > a.Timetable for implementation: Immediate >> > >> > b.Anything else: >> > >> > 7.1. Maintaining IN-ADDRs >> > >> > All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses >> > from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain >> > records for their respective customers. For blocks smaller than /16, and >> > for the segment of larger blocks smaller than /16, ARIN can maintain >> > IN-ADDRs. >> > >> > 6.5.6. Reverse lookup >> > >> > When an RIR delegates IPv6 address space to an organization, it also >> > delegates the responsibility to manage the reverse lookup zone that >> > corresponds to the allocated IPv6 address space. Each organization >> > should properly manage its reverse lookup zone. When making an address >> > assignment, the organization must delegate to an assignee organization, >> > upon request, the responsibility to manage the reverse lookup zone that >> > corresponds to the assigned address. >> > _______________________________________________ >> > 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. >> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 27 Apr 2015 15:14:40 -0400 >> From: ARIN >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy >> ARIN-2014-21: Modification to CI Pool Size per Section 4.4 >> Message-ID: <553E8AA0.3080001 at arin.net> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> The ARIN Advisory Council provided an updated assessment of 2014-21: >> >> "This proposal is technically sound, enables fair and impartial number >> resource administration by ensuring IPv4 resources are available for >> critical infrastructure and Internet exchanges in particular after IPv4 >> resources are no longer readily available from the ARIN free pool. This >> benefits more than just the individual organizations receiving these >> resources; it benefits the entire Internet community by contributing to >> the stability and scalability of the Internet as a whole. Although a >> portion of the community believes the current reservation is sufficient >> and that expanding it will unnecessarily impact those that would have >> otherwise received the resources, the majority of the community polled >> concluded the reservation is justified and supports the proposal." >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> On 4/27/15 12:06 PM, ARIN wrote: >> > The ARIN Advisory Council (AC) met on 15 April 2015 and decided to >> > send the following to last call: >> > >> > Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size >> > per Section 4.4 >> > >> > 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 11 May 2015. After last call the AC will conduct their >> > last call review. >> > >> > The draft policy 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-2014-21 >> > Modification to CI Pool Size per Section 4.4 >> > >> > Date: 25 November 2014 >> > >> > AC's assessment of conformance with the Principles of Internet Number >> > Resource Policy: >> > >> > This proposal enables fair and impartial number resource administration >> > by ensuring IPv4 resources are available for critical infrastructure and >> > Internet Exchanges in particular after IPv4 resources are no longer >> > readily available from the ARIN free pool. This benefits more than just >> > the individual organizations receiving these resources; it benefits the >> > entire Internet Community by contributing to the stability and >> > scalability of the Internet as a whole. This proposal is technically >> > sound and is supported by the community. >> > >> > Problem Statement: >> > >> > At the time that this section of policy was written, IXP growth in North >> > America was stagnant. Efforts of late have increased significantly >> > within the IXP standards and other communities to improve critical >> > infrastructure in North America. This effort is paying dividends and we >> > project that a /16 will not be enough to continue to improve global >> > interconnect conditions and support needed IXP CI infrastructure. >> > >> > Policy statement: >> > >> > Change to text in section 4.4 Micro Allocations: >> > >> > Current text: >> > >> > ARIN will place an equivalent of a /16 of IPv4 address space in a >> > reserve for Critical Infrastructure, as defined in section 4.4. If at >> > the end of the policy term there is unused address space remaining in >> > this pool, ARIN staff is authorized to utilize this space in a manner >> > consistent with community expectations. >> > >> > Proposed text to replace current text entirely: >> > >> > ARIN will place an equivalent of a /15 of IPv4 address space in a >> > reserve for Critical Infrastructure, as defined in section 4.4. >> > >> > Timetable for implementation: Immediate >> > >> > ##### >> > >> > ARIN STAFF ASSESSMENT >> > >> > Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 >> > Date of Assessment: 14 January 2015 >> > >> > 1. Summary (Staff Understanding) >> > >> > This policy changes one section of existing NRPM policy 4.4 to extend >> > the current reservation size for critical infrastructure and exchange >> > points from a /16 equivalent to a /15 equivalent. >> > >> > >> > 2. Comments >> > >> > A. ARIN Staff Comments >> > >> > ??? For informational purposes: >> > ??? A total of 35 /24s have been issued from the reserved /16 equivalent >> > for CI and IXPs since the policy was amended and implemented on 20 March >> > 2013, leaving 221 /24s available in this reserved block. >> > >> > ??? There are currently 381 free /24s remaining in the two /8 ranges >> > used for CI and IXP micro-allocations. >> > >> > ??? This policy could be implemented as written. >> > >> > >> > B. ARIN General Counsel - Legal Assessment >> > >> > This proposal does not create any material legal issue. >> > >> > 3. Resource Impact >> > >> > This policy would have minimal resource impact from an implementation >> > aspect. It is estimated that implementation would occur within 3 months >> > after ratification by the ARIN Board of Trustees. The following would be >> > needed in order to implement: >> > ?? Updated guidelines and internal procedures >> > ?? Staff training >> > >> > 4. Proposal/Draft Policy Text Assessed >> > Draft Policy ARIN-2014-21???Modification to CI Pool Size per Section 4.4 >> > Date: 25 November 2014 >> > Problem Statement: >> > At the time that this section of policy was written, IXP growth in North >> > America was stagnant. Efforts of late have increased significantly >> > within the IXP standards and other communities to improve critical >> > infrastructure in North America. This effort is paying dividends and we >> > project that a /16 will not be enough to continue to improve global >> > interconnect conditions and support needed IXP CI infrastructure. >> > Policy statement: >> > Change to text in section 4.4 Micro Allocations: >> > Current text: >> > ARIN will place an equivalent of a /16 of IPv4 address space in a >> > reserve for Critical Infrastructure, as defined in section 4.4. If at >> > the end of the policy term there is unused address space remaining in >> > this pool, ARIN staff is authorized to utilize this space in a manner >> > consistent with community expectations. >> > Proposed text to replace current text entirely: >> > ARIN will place an equivalent of a /15 of IPv4 address space in a >> > reserve for Critical Infrastructure, as defined in section 4.4. >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 01 May 2015 00:53:03 -0400 >> From: Thomas Narten >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Weekly posting summary for ppml at arin.net >> Message-ID: <201505010453.t414r38B016393 at rotala.raleigh.ibm.com> >> Content-Type: text/plain; charset=us-ascii >> >> Total of 6 messages in the last 7 days. >> >> script run at: Fri May 1 00:53:03 EDT 2015 >> >> Messages | Bytes | Who >> --------+------+--------+----------+------------------------ >> 66.67% | 4 | 65.54% | 39225 | info at arin.net >> 16.67% | 1 | 23.01% | 13773 | michael at linuxmagic.com >> 16.67% | 1 | 11.45% | 6851 | narten at us.ibm.com >> --------+------+--------+----------+------------------------ >> 100.00% | 6 |100.00% | 59849 | Total >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 01 May 2015 18:01:05 -0400 >> From: ARIN >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Advisory Council Meeting Results - April 2015 >> Message-ID: <5543F7A1.7010301 at arin.net> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> > The AC abandoned 2014-1, 2014-14 and 2014-22. Anyone dissatisfied with >> > these decisions 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 minutes from the ARIN Advisory Council's 19 February meeting have >> been published: >> https://www.arin.net/about_us/ac/ac2015_0415.html >> >> The petition deadline is 8 May 2015. >> >> For more information on starting and participating in petitions, see PDP >> Petitions at: https://www.arin.net/policy/pdp_petitions.html >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policy and Proposal texts are available at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> >> On 4/27/15 12:05 PM, ARIN wrote: >> > In accordance with the ARIN Policy Development Process (PDP), the ARIN >> > Advisory Council (AC) met on 15 April 2015. >> > >> > The AC moved the following to last call (to be posted separately to last >> > call): >> > >> > Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS >> > Text >> > Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size >> > per Section 4.4 >> > >> > The AC abandoned the following: >> > >> > Recommended Draft Policy ARIN-2014-1: Out of Region Use >> > Recommended Draft Policy ARIN-2014-14: Removing Needs Test from Small >> > IPv4 Transfers >> > Recommended Draft Policy ARIN-2014-22: Removal of Minimum in Section >> > 4.10 >> > >> > The AC provided the following statements: >> > >> > Regarding ARIN-2014-1: Out of Region Use: >> > >> > "After taking into careful consideration feedback from the ARIN >> > community, both on PPML and at ARIN 35, the AC voted to abandon 2014-1. >> > >> > The AC's consensus is that more work is needed in clarifying and >> > resolving issues in this area and that a new proposal is more likely to >> > yield favorable results than continued efforts to tweak the existing >> > proposal, which has morphed considerably from the original author's >> > intent. To that end, there are AC members currently working to craft a >> > new proposal in this problem space." >> > >> > Regarding ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers: >> > >> > "In its meeting on April 15th, 2015 following ARIN35, the ARIN advisory >> > council voted to abandon Draft Policy 2014-14 due to lack of support in >> > the community, as expressed in the Public Policy Meeting and on PPML." >> > >> > Regarding ARIN-2014-22: Removal of Minimum in Section 4.10: >> > >> > "The ARIN Advisory Council, based on input from the community, has voted >> > to abandon ARIN 2014-22 Removal of Minimum in Section 4.10. >> > >> > The primary goal of Section 4.10 is to provide small blocks of IPv4 >> > space to new entrants for IPv6. The removal of the minimum would have >> > significantly reduced the number of blocks available. >> > >> > While blocks smaller than /24 are not widely routable today, the >> > Advisory Council believes the change would be premature. >> > >> > As a first step to address routability concerns, the AC also recommends >> > that ARIN take additional measures to increase awareness of the specific >> > /10 netblock reserved for assignments under 4.10." >> > >> > == >> > >> > The AC is continuing to work on: >> > >> > Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial >> > End-User Assignments >> > >> > The AC found the revisions to the ARIN NRPM Section 5 (as posted to PPML >> > on 24 February 2015) to be editorial in nature and recommended they be >> > adopted by the ARIN Board of Trustees. >> > >> > The AC abandoned 2014-1, 2014-14 and 2014-22. Anyone dissatisfied with >> > these decisions may initiate a petition. The deadline to begin a >> > petition will be five business days after the AC's draft meeting minutes >> > are published. For more information on starting and participating in >> > petitions, see PDP Petitions at: >> > https://www.arin.net/policy/pdp_petitions.html >> > >> > Draft Policy and Proposal texts are available at: >> > https://www.arin.net/policy/proposals/index.html >> > >> > The ARIN Policy Development Process can be found at: >> > https://www.arin.net/policy/pdp.html >> > >> > Regards, >> > >> > Communications and Member Services >> > American Registry for Internet Numbers (ARIN) >> >> >> >> ------------------------------ >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> End of ARIN-PPML Digest, Vol 119, Issue 1 >> ***************************************** >> > _______________________________________________ > 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 Thu May 7 14:34:57 2015 From: info at arin.net (ARIN) Date: Thu, 07 May 2015 14:34:57 -0400 Subject: [arin-ppml] Board Adopted 2014-17: Change Utilization Requirements from last-allocation to total-aggregate Message-ID: <554BB051.2030603@arin.net> On 13 April 2015 the ARIN Board of Trustees adopted the following number policy: Recommended Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate 2014-17 will be implemented no later than 17 July 2015. This is in accordance with the staff assessment that rated the resource impact of this policy as minimal, requiring three months to implement. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri May 8 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 08 May 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201505080453.t484r2La003144@rotala.raleigh.ibm.com> Total of 5 messages in the last 7 days. script run at: Fri May 8 00:53:01 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 40.00% | 2 | 87.52% | 143401 | rudi.daniel at gmail.com 40.00% | 2 | 8.53% | 13976 | info at arin.net 20.00% | 1 | 3.95% | 6469 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 5 |100.00% | 163846 | Total From info at arin.net Wed May 13 11:40:58 2015 From: info at arin.net (ARIN) Date: Wed, 13 May 2015 11:40:58 -0400 Subject: [arin-ppml] Board Adopted 2014-17: Change Utilization Requirements from last-allocation to total-aggregate In-Reply-To: <554BB051.2030603@arin.net> References: <554BB051.2030603@arin.net> Message-ID: <5553708A.90407@arin.net> 2014-17 will be implemented earlier than we indicated below; it will be implemented no later than 26 June 2015. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 5/7/15 2:34 PM, ARIN wrote: > On 13 April 2015 the ARIN Board of Trustees adopted the following number > policy: > > Recommended Draft Policy ARIN-2014-17: Change Utilization > Requirements from last-allocation to total-aggregate > > 2014-17 will be implemented no later than 17 July 2015. This is in > accordance with the staff assessment that rated the resource impact of > this policy as minimal, requiring three months to implement. > > Board of Trustees Meeting Minutes are available at: > https://www.arin.net/about_us/bot/index.html > > Draft Policy and Policy Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri May 15 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 15 May 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201505150453.t4F4r3DZ021603@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri May 15 00:53:03 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 53.56% | 6520 | narten at us.ibm.com 50.00% | 1 | 46.44% | 5653 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 12173 | Total From David.Huberman at microsoft.com Fri May 15 23:22:39 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Sat, 16 May 2015 03:22:39 +0000 Subject: [arin-ppml] Request for staff: 4-byte ASN data Message-ID: Staff, The 4-byte ASN vs. 2-byte ASN debate is raging in the RIPE address policy working group. In conversations with folks off-line, we've been trying to gauge how much of a problem the lack of 4-byte ASN support from some vendors is for smaller networks. We know that big guys have problems with some gear not supporting advanced feature sets, but it's much harder to get good data on how bad (or not) the little network operators have it. Some time back, ARIN produced stats on the number of exchanges - a situation where ARIN would issue a 4-byte AS number to a requestor, and then some weeks or months later, the requestor would return to ARIN and ask ARIN to exchange the 4-byte ASN for a 2-byte, because 'the 4-byte ASN didn't work". Can we have some insight into the last 12 months of data on this? Specifically: How many 4-byte ASNs were issued? How many have been exchanged for a 2-byte ASN? Is there any anonymized colloquial data you can share that seems common among exchangers/requestors? Thank you kindly. David David R Huberman Principal, Global IP Addressing Microsoft Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Sat May 16 12:23:55 2015 From: michael at linuxmagic.com (Michael Peddemors) Date: Sat, 16 May 2015 09:23:55 -0700 Subject: [arin-ppml] Request for staff: 4-byte ASN data In-Reply-To: References: Message-ID: <55576F1B.8040806@linuxmagic.com> On 15-05-15 08:22 PM, David Huberman wrote: > Staff, > > The 4-byte ASN vs. 2-byte ASN debate is raging in the RIPE address > policy working group. In conversations with folks off-line, we?ve been > trying to gauge how much of a problem the lack of 4-byte ASN support > from some vendors is for smaller networks. We know that big guys have > problems with some gear not supporting advanced feature sets, but it?s > much harder to get good data on how bad (or not) the little network > operators have it. > Took one of our upstream providers almost 2 months before they could support our 4-byte ASN.. It should be noted that this can affect how long it takes a company to get utilization numbers up.. -- "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 nj at jellydigital.net Sat May 16 13:21:32 2015 From: nj at jellydigital.net (Norman Jester) Date: Sat, 16 May 2015 10:21:32 -0700 Subject: [arin-ppml] Request for staff: 4-byte ASN data In-Reply-To: References: Message-ID: <3593B8F1-AE68-4755-A84D-DFEDE26B3249@jellydigital.net> > On May 15, 2015, at 8:22 PM, David Huberman wrote: > > Staff, > > The 4-byte ASN vs. 2-byte ASN debate is raging in the RIPE address policy working group. In conversations with folks off-line, we?ve been trying to gauge how much of a problem the lack of 4-byte ASN support from some vendors is for smaller networks. We know that big guys have problems with some gear not supporting advanced feature sets, but it?s much harder to get good data on how bad (or not) the little network operators have it. We have one contract that is going on 7 months now with no progress. The proposed solution by the provider is ?could you please get a different ASN?. It seems they would rather have their income from our contract on pause rather then upgrade and/or provision a workaround. In addition to that we were told by yet another alternate provider who is to support the same contract that it will take a few months to support this. Norman Jester Jelly Digital, LLC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Sat May 16 20:09:22 2015 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 16 May 2015 20:09:22 -0400 (EDT) Subject: [arin-ppml] Request for staff: 4-byte ASN data In-Reply-To: <55576F1B.8040806@linuxmagic.com> References: <55576F1B.8040806@linuxmagic.com> Message-ID: On Sat, 16 May 2015, Michael Peddemors wrote: > Took one of our upstream providers almost 2 months before they could support > our 4-byte ASN.. > > It should be noted that this can affect how long it takes a company to get > utilization numbers up.. Were they willing to tell you what it was about their network that couldn't support adding a transit customer with a 4-byte ASN? Cisco and Juniper have supported these for years. If they're running older code that doesn't support them, a software update is probably long overdue. The only real annoying issue I've encountered with 4-byte ASNs is that networks that support community tags for TE generally can't do it for 4-byte ASNs since the usual way is tags like ASN:code where the code says what to do when advertising to the ASN. Since standard communities are only 32-bits, and the human readable format is 16-bits:16-bits, 32-bit ASNs "don't fit" unless you make the whole system less human readable and assign a sequential number to each peer, using those in place of ASN in the community tags. Extended communities are big enough to work for this sort of thing, but I'm not aware of anyone using them that way, and AFAIK, platform support for such is limited. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From richardj at arin.net Tue May 19 10:30:33 2015 From: richardj at arin.net (Richard Jimmerson) Date: Tue, 19 May 2015 14:30:33 +0000 Subject: [arin-ppml] Request for staff: 4-byte ASN data Message-ID: Hello David, Thank you for your inquiry about 4-byte AS number registration data at ARIN. For the last several years ARIN has been registering AS numbers by issuing the lowest AS number we have in inventory to approved organizations. We ask those organizations if they would be willing to accept an AS number higher in the number range, and outside of the range that previously made up the 2-byte only AS number space. In 2014 we found that nearly 27% of the organizations approved for an AS number elected to receive a 4-byte AS number rather than take the lowest AS number in our inventory. Several organizations unwilling to receive a 4-byte AS number have indicated to ARIN that their transit providers strongly state a preference that their customers use AS numbers from the traditional 2-byte AS number range. More recently, because of a lack of 2-byte AS numbers in the ARIN inventory, the AS number assignments we make are 4-byte AS numbers and outside of the range that previously made up the 2-byte only AS number space. For those organizations who come back to ARIN specifically stating a preference for a 2-byte AS number, we may be able to continue satisfying their requests using AS numbers that have recently been added to the ARIN AS number inventory through returns or revocations. Very recently ARIN received a new assignment of AS numbers from the IANA. Roughly 90 of those were from the 2-byte range. In 2014 there were 12 organizations that elected to receive a 4-byte AS number and later came back to ARIN to exchange it for a 2-byte AS number. Each of these organizations stated issues with their transit providers either unwilling or unable to accept the use of a 4-byte AS number by a customer. 2014 total AS numbers issued: 1,579 2014 4-byte AS numbers issued: 416 2014 2-byte AS numbers issued: 1,163 Thank you again. Richard Jimmerson CIO & Acting Director of Registration Services American Registry for Internet Numbers From: David Huberman > Date: Friday, May 15, 2015 at 11:22 PM To: "ARIN PPML (ppml at arin.net)" > Subject: [arin-ppml] Request for staff: 4-byte ASN data Staff, The 4-byte ASN vs. 2-byte ASN debate is raging in the RIPE address policy working group. In conversations with folks off-line, we?ve been trying to gauge how much of a problem the lack of 4-byte ASN support from some vendors is for smaller networks. We know that big guys have problems with some gear not supporting advanced feature sets, but it?s much harder to get good data on how bad (or not) the little network operators have it. Some time back, ARIN produced stats on the number of exchanges ? a situation where ARIN would issue a 4-byte AS number to a requestor, and then some weeks or months later, the requestor would return to ARIN and ask ARIN to exchange the 4-byte ASN for a 2-byte, because ?the 4-byte ASN didn?t work?. Can we have some insight into the last 12 months of data on this? Specifically: How many 4-byte ASNs were issued? How many have been exchanged for a 2-byte ASN? Is there any anonymized colloquial data you can share that seems common among exchangers/requestors? Thank you kindly. David David R Huberman Principal, Global IP Addressing Microsoft Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Wed May 20 13:13:25 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 20 May 2015 17:13:25 +0000 Subject: [arin-ppml] Request for staff: 4-byte ASN data In-Reply-To: References: Message-ID: Per Richard's statistics, there were 416 4-byte ASNs issued in CY2014. 12 were returned to ARIN as non-useable. That means that here, on May 20 2015, we should see most of the 404 4-byte ASNs registered in some copy of the DFZ. So let's see! Methodology: - I downloaded 'delegated-arin-extended-latest', today's extended file - I found exactly 421 4-byte ASNs with a registration date in 2014. - I hopped on a Microsoft router and did: show route advertising-protocol bgp [our IP address] aspath-regex ".*(65536-4294967295).*" Interestingly, we found 39,293 prefixes announced or transiting 4-byte ASNs. That's a lot more than expected. - I then looked for all 421 registered 4-byte ASNs from CY2014 in the routing table. Results: 289 4-byte ASNs were found in my company's copy of the DFZ (69%) 132 4-byte ASNs were NOT found (31%) David R Huberman Principal, Global IP Addressing Microsoft Corporation From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Richard Jimmerson Sent: Tuesday, May 19, 2015 7:31 AM To: ARIN PPML (ppml at arin.net) Subject: Re: [arin-ppml] Request for staff: 4-byte ASN data Hello David, Thank you for your inquiry about 4-byte AS number registration data at ARIN. For the last several years ARIN has been registering AS numbers by issuing the lowest AS number we have in inventory to approved organizations. We ask those organizations if they would be willing to accept an AS number higher in the number range, and outside of the range that previously made up the 2-byte only AS number space.? In 2014 we found that nearly 27% of the organizations approved for an AS number elected to receive a 4-byte AS number rather than take the lowest AS number in our inventory. Several organizations unwilling to receive a 4-byte AS number have indicated to ARIN that their transit providers strongly state a preference that their customers use AS numbers from the traditional 2-byte AS number range.? More recently, because of a lack of 2-byte AS numbers in the ARIN inventory, the AS number assignments we make are 4-byte AS numbers and outside of the range that previously made up the 2-byte only AS number space. For those organizations who come back to ARIN specifically stating a preference for a 2-byte AS number, we may be able to continue satisfying their requests using AS numbers that have recently been added to the ARIN AS number inventory through returns or revocations. Very recently ARIN received a new assignment of AS numbers from the IANA. Roughly 90 of those were from the 2-byte range. In 2014 there were 12 organizations that elected to receive a 4-byte AS number and later came back to ARIN to exchange it for a 2-byte AS number. Each of these organizations stated issues with their transit providers either unwilling or unable to accept the use of a 4-byte AS number by a customer. 2014 total AS numbers issued: ?1,579 2014 4-byte AS numbers issued: ?416 2014 2-byte AS numbers issued: ?1,163 Thank you again. Richard Jimmerson CIO & Acting Director of Registration Services American Registry for Internet Numbers From: David Huberman Date: Friday, May 15, 2015 at 11:22 PM To: "ARIN PPML (ppml at arin.net)" Subject: [arin-ppml] Request for staff: 4-byte ASN data Staff, ? The 4-byte ASN vs. 2-byte ASN debate is raging in the RIPE address policy working group.? In conversations with folks off-line, we've been trying to gauge how much of a problem the lack of 4-byte ASN support from some vendors is for smaller networks.? We know that big guys have problems with some gear not supporting advanced feature sets, but it's much harder to get good data on how bad (or not) the little network operators have it. ? Some time back, ARIN produced stats on the number of exchanges - a situation where ARIN would issue a 4-byte AS number to a requestor, and then some weeks or months later, the requestor would return to ARIN and ask ARIN to exchange the 4-byte ASN for a 2-byte, because 'the 4-byte ASN didn't work". ? Can we have some insight into the last 12 months of data on this? Specifically: ? How many 4-byte ASNs were issued? How many have been exchanged for a 2-byte ASN? Is there any anonymized colloquial data you can share that seems common among exchangers/requestors? ? Thank you kindly. David ? David R Huberman Principal, Global IP Addressing Microsoft Corporation ? From narten at us.ibm.com Fri May 22 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 22 May 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201505220453.t4M4r3vs014466@rotala.raleigh.ibm.com> Total of 7 messages in the last 7 days. script run at: Fri May 22 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 28.57% | 2 | 34.03% | 23654 | david.huberman at microsoft.com 14.29% | 1 | 23.27% | 16174 | richardj at arin.net 14.29% | 1 | 14.31% | 9943 | nj at jellydigital.net 14.29% | 1 | 9.53% | 6625 | michael at linuxmagic.com 14.29% | 1 | 9.51% | 6613 | jlewis at lewis.org 14.29% | 1 | 9.35% | 6497 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 7 |100.00% | 69506 | Total From info at arin.net Tue May 26 14:57:55 2015 From: info at arin.net (ARIN) Date: Tue, 26 May 2015 14:57:55 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2015 Message-ID: <5564C233.9040708@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 21 May 2015. The AC recommended the following to the ARIN Board for adoption: Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 The AC accepted the following Proposals as Draft Policies (each will be posted for discussion): ARIN-prop-216 Modify 8.4 (Inter-RIR Transfers to Specified Recipients) ARIN-prop-217 Remove 30 day utilization requirement in end-user IPv4 policy ARIN-prop-218 Modify 8.2 section to better reflect how ARIN handles reorganizations The AC is continuing to work on: Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue May 26 14:58:13 2015 From: info at arin.net (ARIN) Date: Tue, 26 May 2015 14:58:13 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Message-ID: <5564C245.7050207@arin.net> Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients) On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-216 Modify 8.4 (Inter-RIR Transfers to Specified Recipients)" as a Draft Policy. Draft Policy ARIN-2015-2 is below and can be found at: https://www.arin.net/policy/proposals/2015_2.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-2 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Date: 26 May 2015 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 4, to read: "Source entities within the ARIN region must not have received an allocation or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request." Comments: 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; 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. In addition this will not affect the assignments and allocations issued by ARIN they will still be subject to the 12 month restriction. a. Timetable for implementation: Immediate b. Anything else From info at arin.net Tue May 26 14:58:26 2015 From: info at arin.net (ARIN) Date: Tue, 26 May 2015 14:58:26 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Message-ID: <5564C252.4060904@arin.net> Draft Policy ARIN-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-217 Remove 30 day utilization requirement in end-user IPv4 policy" as a Draft Policy. Draft Policy ARIN-2015-3 is below and can be found at: https://www.arin.net/policy/proposals/2015_3.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-3 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy Date: 26 May 2015 Problem Statement: End-user policy is intended to provide end-users with a one year supply of IP addresses. Qualification for a one-year supply requires the network operator to utilize at least 25% of the requested addresses within 30 days. This text is unrealistic and should be removed. First, it often takes longer than 30 days to stage equipment and start actually using the addresses. Second, growth is often not that regimented; the forecast is to use X addresses over the course of a year, not to use 25% of X within 30 days. Third, this policy text applies to additional address space requests. It is incompatible with the requirements of other additional address space request justification which indicates that 80% utilization of existing space is sufficient to justify new space. If a block is at 80%, then often (almost always?) the remaining 80% will be used over the next 30 days and longer. Therefore the operator cannot honestly state they will use 25% of the ADDITIONAL space within 30 days of receiving it; they're still trying to use their older block efficiently. Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give out /24 (or larger) blocks. So the justification for the 25% rule that previously existed (and in fact, applied for many years) is no longer germane. Policy statement: Remove the 25% utilization criteria bullet point from NRPM 4.3.3. Comments: a.Timetable for implementation: Immediate b.Anything else From info at arin.net Tue May 26 14:58:38 2015 From: info at arin.net (ARIN) Date: Tue, 26 May 2015 14:58:38 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations Message-ID: <5564C25E.7090206@arin.net> Draft Policy ARIN-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-218 Modify 8.2 section to better reflect how ARIN handles reorganizations" as a Draft Policy. Draft Policy ARIN-2015-4 is below and can be found at: https://www.arin.net/policy/proposals/2015_4.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-4 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations Problem Statement: ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN procedures handle reorganizations. ARIN staff indicated that the first policy bullet point does not apply to reorganizations. Policy statement: Replacement text for entire 8.2 section: 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. In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy. Comments: The problem statement is addressed by: -re-title 8.2 -clarify the documentation bullet point -rearrange the documentation bullet to the end of the list since it only applies to some requestors, while the other bullet points apply to all requestors. a.Timetable for implementation: Immediate b.Anything else From bill at herrin.us Tue May 26 15:45:16 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 15:45:16 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: <5564C252.4060904@arin.net> References: <5564C252.4060904@arin.net> Message-ID: On Tue, May 26, 2015 at 2:58 PM, ARIN wrote: > Draft Policy ARIN-2015-3 > Remove 30 day utilization requirement in end-user IPv4 policy > Policy statement: > > Remove the 25% utilization criteria bullet point from NRPM 4.3.3. > Problem Statement: > > End-user policy is intended to provide end-users with a one year supply of > IP addresses. Qualification for a one-year supply requires the network > operator to utilize at least 25% of the requested addresses within 30 days. > This text is unrealistic and should be removed. > > First, it often takes longer than 30 days to stage equipment and start > actually using the addresses. > > Second, growth is often not that regimented; the forecast is to use X > addresses over the course of a year, not to use 25% of X within 30 days. Opposed. The intention is that an end-user requesting address space already have an operational network. Some or all of the 25% utilization will be achieved by renumbering a subset of services out of provider-assigned address space. "End user must already operate a real network" is hard to write up in policy language. "25%" is much easier define and accomplishes a comparable goal. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Tue May 26 15:50:46 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 15:50:46 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564C245.7050207@arin.net> References: <5564C245.7050207@arin.net> Message-ID: On Tue, May 26, 2015 at 2:58 PM, ARIN wrote: > Draft Policy ARIN-2015-2 > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > 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 4, to read: > > "Source entities within the ARIN region must not have received an allocation > or assignment of IPv4 number resources from ARIN for the 12 months prior to > the approval of a transfer request." Opposed. BGP does not respect RIR boundaries. Barring pretty transparent fraud, there is no _operational_ need to transfer addresses acquired in the ARIN region to different registry within the 12-month waiting period. Unexpected change in business plan? Who do you think you're fooling? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From David.Huberman at microsoft.com Tue May 26 15:52:24 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 26 May 2015 19:52:24 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: Hi Bill, The 25% text applies not only to initial assignments, but to: - additional assignments - transfers - criteria used by ISPs to determine justification for downstream assignments In the antiseptic world of "ARIN to new end-user getting first assignment", the 25% makes sense. In the other cases, which seem much more relevant in 2015 than the antiseptic case, the 25% doesn't make sense, and in many cases, cannot be met. David > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Tuesday, May 26, 2015 12:45 PM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization > requirement in end-user IPv4 policy > > On Tue, May 26, 2015 at 2:58 PM, ARIN wrote: > > Draft Policy ARIN-2015-3 > > Remove 30 day utilization requirement in end-user IPv4 policy > > > Policy statement: > > > > Remove the 25% utilization criteria bullet point from NRPM 4.3.3. > > > Problem Statement: > > > > End-user policy is intended to provide end-users with a one year > > supply of IP addresses. Qualification for a one-year supply requires > > the network operator to utilize at least 25% of the requested addresses > within 30 days. > > This text is unrealistic and should be removed. > > > > First, it often takes longer than 30 days to stage equipment and start > > actually using the addresses. > > > > Second, growth is often not that regimented; the forecast is to use X > > addresses over the course of a year, not to use 25% of X within 30 days. > > Opposed. > > The intention is that an end-user requesting address space already have an > operational network. Some or all of the 25% utilization will be achieved by > renumbering a subset of services out of provider-assigned address space. > > "End user must already operate a real network" is hard to write up in policy > language. "25%" is much easier define and accomplishes a comparable goal. > > Regards, > Bill Herrin > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, > Dirtside Systems ......... Web: > _______________________________________________ > 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 David.Huberman at microsoft.com Tue May 26 15:57:00 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 26 May 2015 19:57:00 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: Hi Bill, Ever build and operate a network in China? Tina Morris and I, the two policy authors, have and do. There is no BGP in China without IP addresses registered in CNNIC. It's against the law. We, and many other ARIN-region operators, have networks to build and run in China. We cannot do so with the 24 month anti-flip rule in place. "Cannot do so" is not acceptable, so it forces us to 'game' the policy intention by doing an 8.2 to a different OrgID, then doing an 8.4 transfer. So we're paying extra money for extra work by ARIN staff all because of the language in 8.4 -- language which was drafted years ago as a "first-draft" of an anti-flip policy before there was any market. It's 2015, and we have real experience with the market, and real experience operating networks on multiple continents. This draft policy seeks to remedy a real problem. Thanks for listening! David > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Tuesday, May 26, 2015 12:51 PM > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR > Transfers to Specified Recipients) > > On Tue, May 26, 2015 at 2:58 PM, ARIN wrote: > > Draft Policy ARIN-2015-2 > > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > > > 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 4, to read: > > > > "Source entities within the ARIN region must not have received an > > allocation or assignment of IPv4 number resources from ARIN for the 12 > > months prior to the approval of a transfer request." > > Opposed. > > BGP does not respect RIR boundaries. Barring pretty transparent fraud, there > is no _operational_ need to transfer addresses acquired in the ARIN region > to different registry within the 12-month waiting period. > > Unexpected change in business plan? Who do you think you're fooling? > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, > Dirtside Systems ......... Web: > _______________________________________________ > 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 sethm at rollernet.us Tue May 26 16:24:19 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2015 13:24:19 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: <5564D673.7080106@rollernet.us> On 5/26/15 12:57, David Huberman wrote: > There is no BGP in China without IP addresses registered in CNNIC. It's against the law. We, and many other ARIN-region operators, have networks to build and run in China. We cannot do so with the 24 month anti-flip rule in place. Why is another region's policy problem or restrictions something that needs fixing through ARIN policy? ~Seth From David.Huberman at microsoft.com Tue May 26 16:30:19 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 26 May 2015 20:30:19 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564D673.7080106@rollernet.us> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: > Why is another region's policy problem or restrictions something that needs > fixing through ARIN policy? Two answers: Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed. AND Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request. From athompso at athompso.net Tue May 26 16:32:38 2015 From: athompso at athompso.net (Adam Thompson) Date: Tue, 26 May 2015 15:32:38 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564D673.7080106@rollernet.us> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: Conversely, why is it OK for an American organization to impose policies controlling how a company does business in another part of the world? David's argument and problem make sense to me. Affected orgs will just work around the ARIN rules, like they always have... -Adam On May 26, 2015 3:24:19 PM CDT, Seth Mattinen wrote: >On 5/26/15 12:57, David Huberman wrote: >> There is no BGP in China without IP addresses registered in CNNIC. >It's against the law. We, and many other ARIN-region operators, have >networks to build and run in China. We cannot do so with the 24 month >anti-flip rule in place. > > >Why is another region's policy problem or restrictions something that >needs fixing through ARIN policy? > >~Seth >_______________________________________________ >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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Tue May 26 16:38:44 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2015 13:38:44 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: <5564D9D4.3030003@rollernet.us> On 5/26/15 13:30, David Huberman wrote: >> Why is another region's policy problem or restrictions something that needs >> >fixing through ARIN policy? > Two answers: > > Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed. > AND > Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request. > If I am to take an ARIN centric approach I have to ask why I should care about problems in other regions that sound like they could solved by requesting resources from that region. ~Seth From jlewis at lewis.org Tue May 26 16:53:37 2015 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 26 May 2015 16:53:37 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564D9D4.3030003@rollernet.us> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> Message-ID: On Tue, 26 May 2015, Seth Mattinen wrote: > On 5/26/15 13:30, David Huberman wrote: >>> Why is another region's policy problem or restrictions something that >>> needs >>> >fixing through ARIN policy? >> Two answers: >> >> Because ARIN-region networks, subject to ARIN's NRPM, need to be able to >> move IP addresses out of region where and when they're needed. >> AND >> Because ARIN policy currently prohibits staff from counting out-of-region >> use as part of justification for a request. >> > > > If I am to take an ARIN centric approach I have to ask why I should care > about problems in other regions that sound like they could solved by > requesting resources from that region. If you were an ARIN member operating a global network, you probably wouldn't feel that way. I'd argue "many" who do so, but I only have first-hand knowledge of a few ARIN members who do so, prefer as much as possible to deal with one RIR (one set of rules/regulations to keep up with, common language and currency) for their IP space needs. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From farmer at umn.edu Tue May 26 16:59:16 2015 From: farmer at umn.edu (David Farmer) Date: Tue, 26 May 2015 15:59:16 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564D9D4.3030003@rollernet.us> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> Message-ID: > On May 26, 2015, at 15:38, Seth Mattinen wrote: > > On 5/26/15 13:30, David Huberman wrote: >>> Why is another region's policy problem or restrictions something that needs >>> >fixing through ARIN policy? >> Two answers: >> >> Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed. >> AND >> Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request. > > If I am to take an ARIN centric approach I have to ask why I should care about problems in other regions that sound like they could solved by requesting resources from that region. Please explain why you think a "ARIN centric approach" is appropriate to begin with? It a global Internet isn't it? Further, where do you think you will be requesting resources from within another region? People let's get real, these are real problems. I'm not convinced I support the proposed solution, but I'm totally convinced this is a real problem, for real businesses doing legitimate things on the global Internet. These are not nefarious groups trying to commit fraud, or even broker resources, they simply are trying to do legitimate business on the global Internet in a post IPv4 free pool world. From sethm at rollernet.us Tue May 26 17:04:55 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2015 14:04:55 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> Message-ID: <5564DFF7.8070102@rollernet.us> On 5/26/15 13:53, Jon Lewis wrote: > > If you were an ARIN member operating a global network, you probably > wouldn't feel that way. I'd argue "many" who do so, but I only have > first-hand knowledge of a few ARIN members who do so, prefer as much as > possible to deal with one RIR (one set of rules/regulations to keep up > with, common language and currency) for their IP space needs. You're right, I don't operate a global network so I don't really sympathize with such problems. Instead it comes off to me like saying why can't country X's laws be more like Country Y's laws because X makes things harder than in Y and I want to start doing business in X too. That makes me lean towards "oppose". ~Seth From SRyerse at eclipse-networks.com Tue May 26 17:08:36 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 26 May 2015 21:08:36 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564DFF7.8070102@rollernet.us> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> You know, ARIN was first chartered to help further the Internet. Why is it that many here want ARIN to do the opposite? Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? 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 Seth Mattinen Sent: Tuesday, May 26, 2015 5:05 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) On 5/26/15 13:53, Jon Lewis wrote: > > If you were an ARIN member operating a global network, you probably > wouldn't feel that way. I'd argue "many" who do so, but I only have > first-hand knowledge of a few ARIN members who do so, prefer as much > as possible to deal with one RIR (one set of rules/regulations to keep > up with, common language and currency) for their IP space needs. You're right, I don't operate a global network so I don't really sympathize with such problems. Instead it comes off to me like saying why can't country X's laws be more like Country Y's laws because X makes things harder than in Y and I want to start doing business in X too. That makes me lean towards "oppose". ~Seth _______________________________________________ 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 sethm at rollernet.us Tue May 26 17:11:51 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2015 14:11:51 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> Message-ID: <5564E197.4060807@rollernet.us> On 5/26/15 13:59, David Farmer wrote: > Please explain why you think a "ARIN centric approach" is appropriate to begin with? It a global Internet isn't it? A global internet artificially divided into regions each with their own RIR. ~Seth From sethm at rollernet.us Tue May 26 17:13:31 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2015 14:13:31 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> Message-ID: <5564E1FB.1080400@rollernet.us> On 5/26/15 14:08, Steven Ryerse wrote: > You know, ARIN was first chartered to help further the Internet. Why is it that many here want ARIN to do the opposite? Please don't CC me directly, I do actually read the list. ~Seth From bill at herrin.us Tue May 26 17:14:57 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 17:14:57 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: On Tue, May 26, 2015 at 3:57 PM, David Huberman wrote: > There is no BGP in China without IP addresses registered in CNNIC. > It's against the law. [...] it forces us to 'game' the policy intention > by doing an 8.2 to a different OrgID, then doing an 8.4 transfer. So basically, you'd like to do an end run around the law in China and it would be oh so helpful if ARIN would cooperate? Get your Chinese IP addresses through CNNIC. This is Not Our Problem. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Tue May 26 17:17:14 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 17:17:14 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> Message-ID: On Tue, May 26, 2015 at 5:08 PM, Steven Ryerse wrote: > You know, ARIN was first chartered to help further the Internet. > Why is it that many here want ARIN to do the opposite? Because you're mistaken. That's ISOC's charter. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Tue May 26 17:09:51 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 17:09:51 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: On Tue, May 26, 2015 at 3:52 PM, David Huberman wrote: > The 25% text applies not only to initial assignments, but to: > - additional assignments > - transfers Then change the 25% 30-day requirement to apply in aggregate across all direct assignments held by the organization instead of applying to just the most recent. > - criteria used by ISPs to determine justification for downstream assignments You are aware of an incident where an end-user could not get a reasonable IP addresses assignment from an ISP -solely- because they could not meet a 25% initial use requirement? Absent a case study, I'm not inclined to find that argument compelling. Regards. Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jcurran at arin.net Tue May 26 18:05:26 2015 From: jcurran at arin.net (John Curran) Date: Tue, 26 May 2015 22:05:26 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> Message-ID: <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> On May 26, 2015, at 5:17 PM, William Herrin > wrote: On Tue, May 26, 2015 at 5:08 PM, Steven Ryerse > wrote: You know, ARIN was first chartered to help further the Internet. Why is it that many here want ARIN to do the opposite? Because you're mistaken. That's ISOC's charter. For clarity - ARIN was specifically formed to perform the IP addressing functions which were being done prior to that time under the InterNIC cooperative agreement. ARIN?s Articles of Incorporation are extremely broad (as is typical of not-for-profit organizations) and include purposes which could be easily read as "furthering the Internet?. At the time of ARIN?s formation, there were two existing Regional Internet Registries (RIPE NCC, and APNIC), and ARIN?s effectively became the third RIR with its region being ?Rest of World?. The reason for regional registries was not intended for policy purposes, but for administrative convenience for those requesting resources (such as local hours and language support) /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue May 26 18:23:59 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 18:23:59 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> Message-ID: On Tue, May 26, 2015 at 6:05 PM, John Curran wrote: > The reason for regional registries was not intended for policy > purposes, but for administrative convenience for those requesting > resources (such as local hours and language support) Hi John, If you propose that the registries' structure is intended to offer IP addressing "flags of convenience" comparable to what happens with international shipping, please say so plainly. That approach would certainly justify ITU setting up shop as a sixth world-level registry serving governments and international telephony organizations. If that's not your intention, then I frankly have no idea what the quoted statement is supposed to mean and would invite you to clarify it further. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From David.Huberman at microsoft.com Tue May 26 18:38:00 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 26 May 2015 22:38:00 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: > So basically, you'd like to do an end run around the law in China and it would > be oh so helpful if ARIN would cooperate? ??? For clarity: Statement 1: If you acquire a block on the open market and transfer it into your ARIN account, NRPM 8.4 locks it into ARIN for 2 years. Statement 2: If you need to operate in China and get Chinese transit or peering, Chinese law requires the prefix being announced be registered in CNNIC. Statement 1 was intended to prevent flipping/speculating. Statement 2 is Chinese internet policy. A bad actor gets around Statement 1 by transferring the block to a different OrgID in ARIN via NRPM 8.2. Once that transfer occurs, the block in the different OrgID is not subject to Statement 1 . Flipping/speculation can now occur. A good actor has no choice but to get around Statement 1 by transferring the block to a different OrgID in ARIN via NRPM 8.2, then doing an inter-RIR transfer to APNIC (and then to CNNIC). BGP can now occur. In either case, Statement 1 is no-op. From jcurran at arin.net Tue May 26 18:53:48 2015 From: jcurran at arin.net (John Curran) Date: Tue, 26 May 2015 22:53:48 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> Message-ID: <8F732664-2F0A-4030-B32A-F5801F5F18DA@arin.net> On May 26, 2015, at 6:23 PM, William Herrin wrote: > > On Tue, May 26, 2015 at 6:05 PM, John Curran wrote: >> The reason for regional registries was not intended for policy >> purposes, but for administrative convenience for those requesting >> resources (such as local hours and language support) > > Hi John, > > If you propose that the registries' structure is intended to offer IP > addressing "flags of convenience" comparable to what happens with > international shipping, please say so plainly. That approach would > certainly justify ITU setting up shop as a sixth world-level registry > serving governments and international telephony organizations. > > If that's not your intention, then I frankly have no idea what the > quoted statement is supposed to mean and would invite you to clarify > it further. Bill - I was pointing out that the mission of ARIN can be quite large if the community desires such, but it is important to remember that the Regional Internet Registry system (whose origins one can find in RFC 1174) came about in order to scale operational assignment and registration on an international basis, i.e. - The regionalization is not "flags of convenience? situation; it was intended to ?further the Internet? in the operation of the overall registry. Furthermore, the RIR system was not intended as a mechanism for the creation of different policy among the regions; that happened as new policy was created (such as the transfer policies) on a regional basis. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Tue May 26 18:55:07 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 18:55:07 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: On Tue, May 26, 2015 at 6:38 PM, David Huberman wrote: > A good actor has no choice but to get around Statement 1 by transferring > the block to a different OrgID in ARIN via NRPM 8.2, then doing an > inter-RIR transfer to APNIC (and then to CNNIC). BGP can now occur. Hi David, That's a "good" actor? This sort of corrupt behavior that benefits multi-national organizations at the expense of local operators is why I argued against inter-RIR transfers in the first place. I doubt I'll win this argument either, but at least someone will have gone on record calling a spade a spade. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Tue May 26 19:11:06 2015 From: bill at herrin.us (William Herrin) Date: Tue, 26 May 2015 19:11:06 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <8F732664-2F0A-4030-B32A-F5801F5F18DA@arin.net> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> <8F732664-2F0A-4030-B32A-F5801F5F18DA@arin.net> Message-ID: On Tue, May 26, 2015 at 6:53 PM, John Curran wrote: > I was pointing out that the mission of ARIN can be quite large if the > community desires such, but it is important to remember that the > Regional Internet Registry system (whose origins one can find in > RFC 1174) came about in order to scale operational assignment > and registration on an international basis, i.e. - > > The regionalization is not "flags of convenience? situation; it was > intended to ?further the Internet? in the operation of the overall registry. > Furthermore, the RIR system was not intended as a mechanism for > the creation of different policy among the regions; that happened as > new policy was created (such as the transfer policies) on a regional > basis. Hi John, If that's what you truly believe and the rest of the RIR leadership agrees with your viewpoint, may I respectfully suggest that you collectively task the NRO with creating a uniform policy and policy process to replace the regional policies and process we have now. This is one of those things where the middle ground compromise is distinctly worse than either pole. Either act regionally with policies and address pools for use within the region or act globally with policies and address pools for use worldwide. The middle ground lends itself only to unfair advantage for multinational operators who can shop multiple regions for advantage. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From David.Huberman at microsoft.com Tue May 26 19:14:58 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 26 May 2015 23:14:58 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: Bill, I don't understand your position. There's no free pool. All space comes from the market. A small actor pays money to get her necessary space from the market. A large actor pays money to get her necessary space from the market. How does the large actor moving space they hold from ARIN to CNNIC disadvantage the small actor? David > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Tuesday, May 26, 2015 3:55 PM > To: David Huberman > Cc: ARIN PPML (ppml at arin.net) > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR > Transfers to Specified Recipients) > > On Tue, May 26, 2015 at 6:38 PM, David Huberman > wrote: > > A good actor has no choice but to get around Statement 1 by > > transferring the block to a different OrgID in ARIN via NRPM 8.2, then > > doing an inter-RIR transfer to APNIC (and then to CNNIC). BGP can now > occur. > > Hi David, > > That's a "good" actor? This sort of corrupt behavior that benefits multi- > national organizations at the expense of local operators is why I argued > against inter-RIR transfers in the first place. I doubt I'll win this argument > either, but at least someone will have gone on record calling a spade a spade. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, > Dirtside Systems ......... Web: From sethm at rollernet.us Tue May 26 19:23:16 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2015 16:23:16 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: <55650064.6090907@rollernet.us> On 5/26/15 16:14, David Huberman wrote: > Bill, > > I don't understand your position. > > There's no free pool. All space comes from the market. > > A small actor pays money to get her necessary space from the market. > A large actor pays money to get her necessary space from the market. > > How does the large actor moving space they hold from ARIN to CNNIC disadvantage the small actor? > ARIN still appears to have IPv4 inventory to fulfill requests that I think of when I think "small actor", like /24's and /23's. The size that probably can't match what a company like Microsoft can pay for IP space. What do you consider small? ~Seth From athompso at athompso.net Tue May 26 19:57:53 2015 From: athompso at athompso.net (Adam Thompson) Date: Tue, 26 May 2015 18:57:53 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <55650064.6090907@rollernet.us> References: <5564C245.7050207@arin.net> <55650064.6090907@rollernet.us> Message-ID: <37B252D8-FF4C-4C3C-B916-D63BFE1A24B1@athompso.net> Unless I've missed something, the change in question only affects purchased or transferred blocks, not blocks coming from inventory. As far as I know, big and small players already pay the same price in the transfer market. The existing policies only seem to affect large corporations in the first place, so don't disadvantage the small org AFAICT. Considering I'm always complaining about vsmall orgs being ignored, I'd like to see a situation where this change negatively images them, if I've missed it. (Apologies for top-posting from mobile..) -Adam On May 26, 2015 6:23:16 PM CDT, Seth Mattinen wrote: >On 5/26/15 16:14, David Huberman wrote: >> Bill, >> >> I don't understand your position. >> >> There's no free pool. All space comes from the market. >> >> A small actor pays money to get her necessary space from the market. >> A large actor pays money to get her necessary space from the market. >> >> How does the large actor moving space they hold from ARIN to CNNIC >disadvantage the small actor? >> > > >ARIN still appears to have IPv4 inventory to fulfill requests that I >think of when I think "small actor", like /24's and /23's. The size >that >probably can't match what a company like Microsoft can pay for IP >space. >What do you consider small? > >~Seth >_______________________________________________ >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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue May 26 22:06:57 2015 From: jcurran at arin.net (John Curran) Date: Wed, 27 May 2015 02:06:57 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> <8F732664-2F0A-4030-B32A-F5801F5F18DA@arin.net> Message-ID: On May 26, 2015, at 7:11 PM, William Herrin wrote: > ... > If that's what you truly believe and the rest of the RIR leadership > agrees with your viewpoint, may I respectfully suggest that you > collectively task the NRO with creating a uniform policy and policy > process to replace the regional policies and process we have now. Some clarity of terms: - Global policy ? policy used by the IANA registry operator for administration of the IANA Internet number registries - Globally-coordinated policy ? policy used by the RIRs for administration of their regional registries that has been coordinated among the RIRs to be uniform - Regional policy ? policy used by the an RIR for administration of the Internet number registries for that region It is the community, not an asserted ?RIR leadership?, that matters when it comes to policy development, and the community has the tools necessary to develop globally uniform policies if it chooses to do so. > This is one of those things where the middle ground compromise is > distinctly worse than either pole. Either act regionally with policies > and address pools for use within the region or act globally with > policies and address pools for use worldwide. The middle ground lends > itself only to unfair advantage for multinational operators who can > shop multiple regions for advantage. You have a reasonable argument for why there should be globally-coordinated policy in this area. If you need any assistance when developing your proposal, please reach out to the ARIN Advisory Council for assistance. Ultimately, it is up to the globally community whether a globally uniform transfer policy is desirable. Thanks! /John John Curran President and CEO ARIN From owen at delong.com Wed May 27 08:03:45 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 27 May 2015 14:03:45 +0200 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: I could support a policy that allows you to transfer them to your own entity out of region for this purpose if there were some language that prevented subsequent flipping. However, the policy as proposed creates too much opportunity for unintended consequences that the original anti-flip language is intended to prevent. Owen > On May 26, 2015, at 10:30 PM, David Huberman wrote: > >> Why is another region's policy problem or restrictions something that needs >> fixing through ARIN policy? > > Two answers: > > Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed. > AND > Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request. > > _______________________________________________ > 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 Wed May 27 08:09:07 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 27 May 2015 14:09:07 +0200 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: <08519D1D-F30F-4205-A1D1-2CBCA1A9C632@delong.com> You are correct, David? We should restore the anti-flip language that prohibits an organization which received a transfer from subsequently being a provider for any transfer within 24 months. Owen > On May 27, 2015, at 12:38 AM, David Huberman wrote: > >> So basically, you'd like to do an end run around the law in China and it would >> be oh so helpful if ARIN would cooperate? > > ??? > > For clarity: > > Statement 1: If you acquire a block on the open market and transfer it into your ARIN account, NRPM 8.4 locks it into ARIN for 2 years. > > Statement 2: If you need to operate in China and get Chinese transit or peering, Chinese law requires the prefix being announced be registered in CNNIC. > > Statement 1 was intended to prevent flipping/speculating. > Statement 2 is Chinese internet policy. > > A bad actor gets around Statement 1 by transferring the block to a different OrgID in ARIN via NRPM 8.2. Once that transfer occurs, the block in the different OrgID is not subject to Statement 1 . Flipping/speculation can now occur. > > A good actor has no choice but to get around Statement 1 by transferring the block to a different OrgID in ARIN via NRPM 8.2, then doing an inter-RIR transfer to APNIC (and then to CNNIC). BGP can now occur. > > In either case, Statement 1 is no-op. > > > _______________________________________________ > 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 Wed May 27 08:11:58 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 27 May 2015 14:11:58 +0200 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: <313707E5-FBED-4769-96F0-9DEFCF8ADA15@delong.com> The large multinational actor has the option of buying space in the ARIN market and moving it ARIN->APNIC->CNNIC. The small operator in China has trouble competing with the large multinational actor because the small actor has no such option for obtaining IPv4 addresses. (As one example) Owen > On May 27, 2015, at 1:14 AM, David Huberman wrote: > > Bill, > > I don't understand your position. > > There's no free pool. All space comes from the market. > > A small actor pays money to get her necessary space from the market. > A large actor pays money to get her necessary space from the market. > > How does the large actor moving space they hold from ARIN to CNNIC disadvantage the small actor? > > David > >> -----Original Message----- >> From: William Herrin [mailto:bill at herrin.us] >> Sent: Tuesday, May 26, 2015 3:55 PM >> To: David Huberman >> Cc: ARIN PPML (ppml at arin.net) >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR >> Transfers to Specified Recipients) >> >> On Tue, May 26, 2015 at 6:38 PM, David Huberman >> wrote: >>> A good actor has no choice but to get around Statement 1 by >>> transferring the block to a different OrgID in ARIN via NRPM 8.2, then >>> doing an inter-RIR transfer to APNIC (and then to CNNIC). BGP can now >> occur. >> >> Hi David, >> >> That's a "good" actor? This sort of corrupt behavior that benefits multi- >> national organizations at the expense of local operators is why I argued >> against inter-RIR transfers in the first place. I doubt I'll win this argument >> either, but at least someone will have gone on record calling a spade a spade. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, >> Dirtside Systems ......... Web: > _______________________________________________ > 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 rudi.daniel at gmail.com Wed May 27 09:24:44 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 27 May 2015 09:24:44 -0400 Subject: [arin-ppml] 2015-2 Message-ID: >>The large multinational actor has the option of buying space in the ARIN market and moving it ARIN->>APNIC->CNNIC. >>The small operator in China has trouble competing with the large multinational actor because the small actor has no such option for >>obtaining IPv4 addresses.<< If the above is s fair example of current situation, it seems unfair or did advantageous to a smaller operator. So would a set of anti flip words with an allocation size operator work? Or would there be fear of broadening the flip market ? Or I can ask, at what size of allocation does antiflip rules begin to be necessary? RD On May 27, 2015 8:17 AM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Seth Mattinen) > 2. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Adam Thompson) > 3. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (John Curran) > 4. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Owen DeLong) > 5. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Owen DeLong) > 6. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 26 May 2015 16:23:16 -0700 > From: Seth Mattinen > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <55650064.6090907 at rollernet.us> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 5/26/15 16:14, David Huberman wrote: > > Bill, > > > > I don't understand your position. > > > > There's no free pool. All space comes from the market. > > > > A small actor pays money to get her necessary space from the market. > > A large actor pays money to get her necessary space from the market. > > > > How does the large actor moving space they hold from ARIN to CNNIC > disadvantage the small actor? > > > > > ARIN still appears to have IPv4 inventory to fulfill requests that I > think of when I think "small actor", like /24's and /23's. The size that > probably can't match what a company like Microsoft can pay for IP space. > What do you consider small? > > ~Seth > > > ------------------------------ > > Message: 2 > Date: Tue, 26 May 2015 18:57:53 -0500 > From: Adam Thompson > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <37B252D8-FF4C-4C3C-B916-D63BFE1A24B1 at athompso.net> > Content-Type: text/plain; charset="utf-8" > > Unless I've missed something, the change in question only affects > purchased or transferred blocks, not blocks coming from inventory. > As far as I know, big and small players already pay the same price in the > transfer market. > The existing policies only seem to affect large corporations in the first > place, so don't disadvantage the small org AFAICT. Considering I'm always > complaining about vsmall orgs being ignored, I'd like to see a situation > where this change negatively images them, if I've missed it. > (Apologies for top-posting from mobile..) > -Adam > > On May 26, 2015 6:23:16 PM CDT, Seth Mattinen wrote: > >On 5/26/15 16:14, David Huberman wrote: > >> Bill, > >> > >> I don't understand your position. > >> > >> There's no free pool. All space comes from the market. > >> > >> A small actor pays money to get her necessary space from the market. > >> A large actor pays money to get her necessary space from the market. > >> > >> How does the large actor moving space they hold from ARIN to CNNIC > >disadvantage the small actor? > >> > > > > > >ARIN still appears to have IPv4 inventory to fulfill requests that I > >think of when I think "small actor", like /24's and /23's. The size > >that > >probably can't match what a company like Microsoft can pay for IP > >space. > >What do you consider small? > > > >~Seth > >_______________________________________________ > >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. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20150526/350ba519/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 27 May 2015 02:06:57 +0000 > From: John Curran > To: BIll Herrin > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: > Content-Type: text/plain; charset="utf-8" > > On May 26, 2015, at 7:11 PM, William Herrin wrote: > > ... > > If that's what you truly believe and the rest of the RIR leadership > > agrees with your viewpoint, may I respectfully suggest that you > > collectively task the NRO with creating a uniform policy and policy > > process to replace the regional policies and process we have now. > > Some clarity of terms: > > - Global policy ? policy used by the IANA registry operator for > administration > of the IANA Internet number registries > > - Globally-coordinated policy ? policy used by the RIRs for > administration of > their regional registries that has been coordinated among the RIRs to > be > uniform > > - Regional policy ? policy used by the an RIR for administration of the > Internet number registries for that region > > It is the community, not an asserted ?RIR leadership?, that matters when it > comes to policy development, and the community has the tools necessary > to develop globally uniform policies if it chooses to do so. > > > This is one of those things where the middle ground compromise is > > distinctly worse than either pole. Either act regionally with policies > > and address pools for use within the region or act globally with > > policies and address pools for use worldwide. The middle ground lends > > itself only to unfair advantage for multinational operators who can > > shop multiple regions for advantage. > > You have a reasonable argument for why there should be globally-coordinated > policy in this area. If you need any assistance when developing your > proposal, > please reach out to the ARIN Advisory Council for assistance. Ultimately, > it is up > to the globally community whether a globally uniform transfer policy is > desirable. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > ------------------------------ > > Message: 4 > Date: Wed, 27 May 2015 14:03:45 +0200 > From: Owen DeLong > To: David Huberman > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: > Content-Type: text/plain; charset=us-ascii > > I could support a policy that allows you to transfer them to your own > entity out of region for this purpose if there were some language that > prevented subsequent flipping. > > However, the policy as proposed creates too much opportunity for > unintended consequences that the original anti-flip language is intended to > prevent. > > Owen > > > On May 26, 2015, at 10:30 PM, David Huberman < > David.Huberman at microsoft.com> wrote: > > > >> Why is another region's policy problem or restrictions something that > needs > >> fixing through ARIN policy? > > > > Two answers: > > > > Because ARIN-region networks, subject to ARIN's NRPM, need to be able to > move IP addresses out of region where and when they're needed. > > AND > > Because ARIN policy currently prohibits staff from counting > out-of-region use as part of justification for a request. > > > > _______________________________________________ > > 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. > > > > ------------------------------ > > Message: 5 > Date: Wed, 27 May 2015 14:09:07 +0200 > From: Owen DeLong > To: David Huberman > Cc: "ARIN PPML \(ppml at arin.net\)" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <08519D1D-F30F-4205-A1D1-2CBCA1A9C632 at delong.com> > Content-Type: text/plain; charset=utf-8 > > You are correct, David? We should restore the anti-flip language that > prohibits an organization which received a transfer from subsequently being > a provider for any transfer within 24 months. > > Owen > > > On May 27, 2015, at 12:38 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > > > >> So basically, you'd like to do an end run around the law in China and > it would > >> be oh so helpful if ARIN would cooperate? > > > > ??? > > > > For clarity: > > > > Statement 1: If you acquire a block on the open market and transfer it > into your ARIN account, NRPM 8.4 locks it into ARIN for 2 years. > > > > Statement 2: If you need to operate in China and get Chinese transit or > peering, Chinese law requires the prefix being announced be registered in > CNNIC. > > > > Statement 1 was intended to prevent flipping/speculating. > > Statement 2 is Chinese internet policy. > > > > A bad actor gets around Statement 1 by transferring the block to a > different OrgID in ARIN via NRPM 8.2. Once that transfer occurs, the block > in the different OrgID is not subject to Statement 1 . Flipping/speculation > can now occur. > > > > A good actor has no choice but to get around Statement 1 by transferring > the block to a different OrgID in ARIN via NRPM 8.2, then doing an > inter-RIR transfer to APNIC (and then to CNNIC). BGP can now occur. > > > > In either case, Statement 1 is no-op. > > > > > > _______________________________________________ > > 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. > > > > ------------------------------ > > Message: 6 > Date: Wed, 27 May 2015 14:11:58 +0200 > From: Owen DeLong > To: David Huberman > Cc: "ARIN PPML \(ppml at arin.net\)" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <313707E5-FBED-4769-96F0-9DEFCF8ADA15 at delong.com> > Content-Type: text/plain; charset=us-ascii > > The large multinational actor has the option of buying space in the ARIN > market and moving it ARIN->APNIC->CNNIC. > > The small operator in China has trouble competing with the large > multinational actor because the small actor has no such option for > obtaining IPv4 addresses. > > (As one example) > > Owen > > > On May 27, 2015, at 1:14 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > > > > Bill, > > > > I don't understand your position. > > > > There's no free pool. All space comes from the market. > > > > A small actor pays money to get her necessary space from the market. > > A large actor pays money to get her necessary space from the market. > > > > How does the large actor moving space they hold from ARIN to CNNIC > disadvantage the small actor? > > > > David > > > >> -----Original Message----- > >> From: William Herrin [mailto:bill at herrin.us] > >> Sent: Tuesday, May 26, 2015 3:55 PM > >> To: David Huberman > >> Cc: ARIN PPML (ppml at arin.net) > >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR > >> Transfers to Specified Recipients) > >> > >> On Tue, May 26, 2015 at 6:38 PM, David Huberman > >> wrote: > >>> A good actor has no choice but to get around Statement 1 by > >>> transferring the block to a different OrgID in ARIN via NRPM 8.2, then > >>> doing an inter-RIR transfer to APNIC (and then to CNNIC). BGP can now > >> occur. > >> > >> Hi David, > >> > >> That's a "good" actor? This sort of corrupt behavior that benefits > multi- > >> national organizations at the expense of local operators is why I argued > >> against inter-RIR transfers in the first place. I doubt I'll win this > argument > >> either, but at least someone will have gone on record calling a spade a > spade. > >> > >> Regards, > >> Bill Herrin > >> > >> > >> -- > >> William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, > >> Dirtside Systems ......... Web: > > _______________________________________________ > > 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. > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 119, Issue 12 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed May 27 10:33:07 2015 From: bill at herrin.us (William Herrin) Date: Wed, 27 May 2015 10:33:07 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <313707E5-FBED-4769-96F0-9DEFCF8ADA15@delong.com> References: <5564C245.7050207@arin.net> <313707E5-FBED-4769-96F0-9DEFCF8ADA15@delong.com> Message-ID: On Wed, May 27, 2015 at 8:11 AM, Owen DeLong wrote: > The large multinational actor has the option of buying space in the ARIN market and moving it ARIN->APNIC->CNNIC. > > The small operator in China has trouble competing with the large multinational actor because the small actor has no such option for obtaining IPv4 addresses. Just so. IMO, this is so easy to understand one actually has to try hard not to. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Wed May 27 10:39:08 2015 From: bill at herrin.us (William Herrin) Date: Wed, 27 May 2015 10:39:08 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> Message-ID: On Tue, May 26, 2015 at 3:57 PM, David Huberman wrote: > Ever build and operate a network in China? Tina Morris and I, the two policy authors, have and do. Excellent! Since you bring it up, what process do you follow when you want to move addresses originally registered with CNNIC to equipment in the ARIN region? Is reciprocity lawful in China? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jschiller at google.com Wed May 27 11:04:40 2015 From: jschiller at google.com (Jason Schiller) Date: Wed, 27 May 2015 11:04:40 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: I also find the 25% utilization in 30 days problematic for the simple reason that renumbering out of PA space, or turning up new equipment often takes more than 30 days. Imagine a case were an end user has a real commitment to deploy five new offices each with ~210 employees (each employee with a single desktop) over the next quarter. Office space is leased, computers are bought, construction is on going for all five sites, and one site is scheduled to go live in 45 days, 250 offers have been extended for the first site, 50 have accepted, another 200 candidates are in the interview pipeline for the other two sites with a scheduled go live date in the next 60 days. Based on this growth rate, it is likely that 20 sites with approximately 210 employees (and desktops) each will be deployed in the next 12 months. It is anticipated that it will take 45 days to get the 210 computers at the new site physically setup on desks, and connected to a working LAN, with working Internet access. The organization has on hand enough equipment to number 82% of five /24s. With a real one year projection based on past growth for filling 82% of twenty /24s over the next year. One would think this should be sufficient justification for at least a /21 (five /24s round up to eight /24s or a /21) with a real commitment already underway to use these addresses. Once in service more than 50% of a /21 will be in use. There are also a projection for a total of twenty /24s at 82% utilization or 51% of /19 over the next year. This sounds like it should be a good justification for a /20 or a /19. I think the 25% requirement in 30 days is unreasonable, especially when an organization is already committed but the work will take longer than 30 days. But 50% of a purely future looking projection is not strong enough. I think a one year projection based and past one year growth with all currently held subnets 50% full, or 80% usage of all space held, and a commitment to plans to start using the space should be sufficient. I don't know how to deal with initial allocation or slow start especially in a transfer market, but we need to solve that problem wrt ISP, and suspect that slow start mechanism could apply here. ___Jason On May 26, 2015 5:25 PM, "William Herrin" wrote: > On Tue, May 26, 2015 at 3:52 PM, David Huberman > wrote: > > The 25% text applies not only to initial assignments, but to: > > - additional assignments > > - transfers > > Then change the 25% 30-day requirement to apply in aggregate across > all direct assignments held by the organization instead of applying to > just the most recent. > > > > - criteria used by ISPs to determine justification for downstream > assignments > > You are aware of an incident where an end-user could not get a > reasonable IP addresses assignment from an ISP -solely- because they > could not meet a 25% initial use requirement? Absent a case study, I'm > not inclined to find that argument compelling. > > Regards. > Bill Herrin > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > 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 bill at herrin.us Wed May 27 11:43:34 2015 From: bill at herrin.us (William Herrin) Date: Wed, 27 May 2015 11:43:34 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: On Wed, May 27, 2015 at 11:04 AM, Jason Schiller wrote: > Imagine a case were an end user has a real commitment to deploy five new > offices each with ~210 employees (each employee with a single desktop) over > the next quarter. Office space is leased, computers are bought, > construction is on going for all five sites, and one site is scheduled to go > live in 45 days, 250 offers have been extended for the first site, 50 have > accepted, another 200 candidates are in the interview pipeline for the other > two sites with a scheduled go live date in the next 60 days. > > Based on this growth rate, it is likely that 20 sites with approximately 210 > employees (and desktops) each will be deployed in the next 12 months. > > It is anticipated that it will take 45 days to get the 210 computers at the > new site physically setup on desks, and connected to a working LAN, with > working Internet access. > > The organization has on hand enough equipment to number 82% of five /24s. > With a real one year projection based on past growth for filling 82% of > twenty /24s over the next year. > > One would think this should be sufficient justification for at least a /21 > (five /24s round up to eight /24s or a /21) with a real commitment already > underway to use these addresses. Once in service more than 50% of a /21 > will be in use. > > There are also a projection for a total of twenty /24s at 82% utilization or > 51% of > /19 over the next year. > > This sounds like it should be a good justification for a /20 or a /19. > > I think the 25% requirement in 30 days is unreasonable, especially when an > organization is already committed but the work will take longer than 30 > days. But 50% of a purely future looking projection is not strong enough. Hi Jason, For the sake of the argument, I accept your example in whole. That organization did not appear out of thin air, suddenly hire up hundreds of staff and build a bunch of locations. Large organizations don't magically spring into being. They already had a substantial operation and its infrastructure. Changing the 25% 30-day requirement to apply in aggregate across all direct assignments held by the organization would resolve the problem here quite effectively. I also note that the office space is leased and being paid for while construction is ongoing. Given the lead time for data circuits, are not those contracts let as well? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From kevinb at thewire.ca Wed May 27 12:18:07 2015 From: kevinb at thewire.ca (Kevin Blumberg) Date: Wed, 27 May 2015 16:18:07 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: <7E7773B523E82C478734E793E58F69E78DBAD378@SBS2011.thewireinc.local> David, I believe that examples definitely help. Can you confirm these scenario's as you see it. 1) XYZ Company (Australia) can go to the market in the ARIN region and perform a 8.4 transfer. As the company is based in the APNIC region and is not a ARIN customer they are not restricted by the "in region" requirements. 2) XYZ Company (America) wishing to perform an 8.4 transfer to XYZ Company (Australia) would be limited based on the source entity being "in region". Thanks, Kevin Blumberg -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: May 26, 2015 4:30 PM To: Seth Mattinen; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > Why is another region's policy problem or restrictions something that > needs fixing through ARIN policy? Two answers: Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed. AND Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request. _______________________________________________ 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 bill at herrin.us Wed May 27 12:17:55 2015 From: bill at herrin.us (William Herrin) Date: Wed, 27 May 2015 12:17:55 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> <8F732664-2F0A-4030-B32A-F5801F5F18DA@arin.net> Message-ID: On Tue, May 26, 2015 at 10:06 PM, John Curran wrote: > On May 26, 2015, at 7:11 PM, William Herrin wrote: >> This is one of those things where the middle ground compromise is >> distinctly worse than either pole. Either act regionally with policies >> and address pools for use within the region or act globally with >> policies and address pools for use worldwide. The middle ground lends >> itself only to unfair advantage for multinational operators who can >> shop multiple regions for advantage. > > You have a reasonable argument for why there should be globally-coordinated > policy in this area. If you need any assistance when developing your proposal, > please reach out to the ARIN Advisory Council for assistance. Ultimately, it is up > to the globally community whether a globally uniform transfer policy is desirable. Hi John, Respectfully, we have barely a weak consensus, if that, on what the transfer policies should be within the region. There is wide disagreement as to whether transfers should have any form of needs testing save for the movement of tender. In that environment it makes sense to pursue globally coordinated consensus on transfer policies? Surely you jest. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From scottleibrand at gmail.com Wed May 27 12:51:25 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 27 May 2015 11:51:25 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <313707E5-FBED-4769-96F0-9DEFCF8ADA15@delong.com> References: <5564C245.7050207@arin.net> <313707E5-FBED-4769-96F0-9DEFCF8ADA15@delong.com> Message-ID: <0EAA6F11-7394-489F-A4B2-B2309B1280E9@gmail.com> How is it not possible for a "small" (but big enough to require more than the /22 they can get free from APNIC) operator in China to acquire IPv4 space in the ARIN market and move it ARIN->APNIC->CNNIC? There are lots of brokers who are happy to help execute such transactions if the small operator doesn't have the expertise themselves. Scott > On May 27, 2015, at 7:11 AM, Owen DeLong wrote: > > The large multinational actor has the option of buying space in the ARIN market and moving it ARIN->APNIC->CNNIC. > > The small operator in China has trouble competing with the large multinational actor because the small actor has no such option for obtaining IPv4 addresses. > > (As one example) > > Owen > >> On May 27, 2015, at 1:14 AM, David Huberman wrote: >> >> Bill, >> >> I don't understand your position. >> >> There's no free pool. All space comes from the market. >> >> A small actor pays money to get her necessary space from the market. >> A large actor pays money to get her necessary space from the market. >> >> How does the large actor moving space they hold from ARIN to CNNIC disadvantage the small actor? >> >> David >> >>> -----Original Message----- >>> From: William Herrin [mailto:bill at herrin.us] >>> Sent: Tuesday, May 26, 2015 3:55 PM >>> To: David Huberman >>> Cc: ARIN PPML (ppml at arin.net) >>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR >>> Transfers to Specified Recipients) >>> >>> On Tue, May 26, 2015 at 6:38 PM, David Huberman >>> wrote: >>>> A good actor has no choice but to get around Statement 1 by >>>> transferring the block to a different OrgID in ARIN via NRPM 8.2, then >>>> doing an inter-RIR transfer to APNIC (and then to CNNIC). BGP can now >>> occur. >>> >>> Hi David, >>> >>> That's a "good" actor? This sort of corrupt behavior that benefits multi- >>> national organizations at the expense of local operators is why I argued >>> against inter-RIR transfers in the first place. I doubt I'll win this argument >>> either, but at least someone will have gone on record calling a spade a spade. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, >>> Dirtside Systems ......... Web: >> _______________________________________________ >> 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 jschiller at google.com Wed May 27 12:57:21 2015 From: jschiller at google.com (Jason Schiller) Date: Wed, 27 May 2015 12:57:21 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: Under the 25% utilization across all assignments held, an end site with a /24 with 253 hosts, a router, network and broadcast would be 100% utilized. They could then waive their hands and say something about growth, and double to a /23 (total) at 50% utilized, and double again to a /22 (total) at 25% utilization? My impression of the 25% requirement is to have some real world measure to off set a pure future looking indisputable claim. My example attempted to replace the real world measure with some real commitment to have in process things that need IPs that can be counted (but won't necessarily have the IP in service in 30 days). I don't know how you avoid hand wavyness for initial allocation, or make slow start work in a transfer world. ___Jason On Wed, May 27, 2015 at 11:43 AM, William Herrin wrote: > On Wed, May 27, 2015 at 11:04 AM, Jason Schiller > wrote: > > Imagine a case were an end user has a real commitment to deploy five new > > offices each with ~210 employees (each employee with a single desktop) > over > > the next quarter. Office space is leased, computers are bought, > > construction is on going for all five sites, and one site is scheduled > to go > > live in 45 days, 250 offers have been extended for the first site, 50 > have > > accepted, another 200 candidates are in the interview pipeline for the > other > > two sites with a scheduled go live date in the next 60 days. > > > > Based on this growth rate, it is likely that 20 sites with approximately > 210 > > employees (and desktops) each will be deployed in the next 12 months. > > > > It is anticipated that it will take 45 days to get the 210 computers at > the > > new site physically setup on desks, and connected to a working LAN, with > > working Internet access. > > > > The organization has on hand enough equipment to number 82% of five /24s. > > With a real one year projection based on past growth for filling 82% of > > twenty /24s over the next year. > > > > One would think this should be sufficient justification for at least a > /21 > > (five /24s round up to eight /24s or a /21) with a real commitment > already > > underway to use these addresses. Once in service more than 50% of a /21 > > will be in use. > > > > There are also a projection for a total of twenty /24s at 82% > utilization or > > 51% of > > /19 over the next year. > > > > This sounds like it should be a good justification for a /20 or a /19. > > > > I think the 25% requirement in 30 days is unreasonable, especially when > an > > organization is already committed but the work will take longer than 30 > > days. But 50% of a purely future looking projection is not strong > enough. > > Hi Jason, > > For the sake of the argument, I accept your example in whole. > > That organization did not appear out of thin air, suddenly hire up > hundreds of staff and build a bunch of locations. Large organizations > don't magically spring into being. They already had a substantial > operation and its infrastructure. Changing the 25% 30-day requirement > to apply in aggregate across all direct assignments held by the > organization would resolve the problem here quite effectively. > > I also note that the office space is leased and being paid for while > construction is ongoing. Given the lead time for data circuits, are > not those contracts let as well? > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Wed May 27 14:05:35 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 27 May 2015 11:05:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <0EAA6F11-7394-489F-A4B2-B2309B1280E9@gmail.com> References: <5564C245.7050207@arin.net> <313707E5-FBED-4769-96F0-9DEFCF8ADA15@delong.com> <0EAA6F11-7394-489F-A4B2-B2309B1280E9@gmail.com> Message-ID: <5566076F.4050000@matthew.at> And if they're small enough, they can't afford any IP space on the transfer market... but then, yes, either the free /22 should be enough or maybe they can't afford to be in China anyway. Eventually all large blocks of IPv4 space will be very expensive... and changing ARIN policy isn't going to make that any less true or any more "fair". Matthew Kaufman On 5/27/2015 9:51 AM, Scott Leibrand wrote: > How is it not possible for a "small" (but big enough to require more than the /22 they can get free from APNIC) operator in China to acquire IPv4 space in the ARIN market and move it ARIN->APNIC->CNNIC? There are lots of brokers who are happy to help execute such transactions if the small operator doesn't have the expertise themselves. > > Scott > >> On May 27, 2015, at 7:11 AM, Owen DeLong wrote: >> >> The large multinational actor has the option of buying space in the ARIN market and moving it ARIN->APNIC->CNNIC. >> >> The small operator in China has trouble competing with the large multinational actor because the small actor has no such option for obtaining IPv4 addresses. >> >> (As one example) >> >> Owen >> >>> On May 27, 2015, at 1:14 AM, David Huberman wrote: >>> >>> Bill, >>> >>> I don't understand your position. >>> >>> There's no free pool. All space comes from the market. >>> >>> A small actor pays money to get her necessary space from the market. >>> A large actor pays money to get her necessary space from the market. >>> >>> How does the large actor moving space they hold from ARIN to CNNIC disadvantage the small actor? >>> >>> David >>> >>>> -----Original Message----- >>>> From: William Herrin [mailto:bill at herrin.us] >>>> Sent: Tuesday, May 26, 2015 3:55 PM >>>> To: David Huberman >>>> Cc: ARIN PPML (ppml at arin.net) >>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR >>>> Transfers to Specified Recipients) >>>> >>>> On Tue, May 26, 2015 at 6:38 PM, David Huberman >>>> wrote: >>>>> A good actor has no choice but to get around Statement 1 by >>>>> transferring the block to a different OrgID in ARIN via NRPM 8.2, then >>>>> doing an inter-RIR transfer to APNIC (and then to CNNIC). BGP can now >>>> occur. >>>> >>>> Hi David, >>>> >>>> That's a "good" actor? This sort of corrupt behavior that benefits multi- >>>> national organizations at the expense of local operators is why I argued >>>> against inter-RIR transfers in the first place. I doubt I'll win this argument >>>> either, but at least someone will have gone on record calling a spade a spade. >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> >>>> -- >>>> William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, >>>> Dirtside Systems ......... Web: >>> _______________________________________________ >>> 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. > _______________________________________________ > 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 jcurran at arin.net Wed May 27 14:06:07 2015 From: jcurran at arin.net (John Curran) Date: Wed, 27 May 2015 18:06:07 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> <8F732664-2F0A-4030-B32A-F5801F5F18DA@arin.net> Message-ID: <65F58738-8342-4BF0-8D1A-DF0AE7E7EC97@arin.net> On May 27, 2015, at 12:17 PM, William Herrin wrote: > > On Tue, May 26, 2015 at 10:06 PM, John Curran wrote: >> You have a reasonable argument for why there should be globally-coordinated >> policy in this area. If you need any assistance when developing your proposal, >> please reach out to the ARIN Advisory Council for assistance. Ultimately, it is up >> to the globally community whether a globally uniform transfer policy is desirable. > > Hi John, > > Respectfully, we have barely a weak consensus, if that, on what the > transfer policies should be within the region. That may be the case. > There is wide disagreement as to whether transfers should have any form of needs > testing save for the movement of tender. In that environment it makes sense to pursue > globally coordinated consensus on transfer policies? Surely you jest. Bill - You indicated that the present state was distinctly worse that having globally coordinated policy; I pointed out that the community had the ability to define globally coordinated policy if desired (and offered you assistance if needed.) If the community cannot come together in consensus on globally coordinated policy, then your observation about the present state being worse than a global policy approach doesn?t really matter, and you can disregard my note. Thanks, /John John Curran President and CEO ARIN From bill at herrin.us Wed May 27 14:24:15 2015 From: bill at herrin.us (William Herrin) Date: Wed, 27 May 2015 14:24:15 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <65F58738-8342-4BF0-8D1A-DF0AE7E7EC97@arin.net> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> <5564DFF7.8070102@rollernet.us> <5B9E90747FA2974D91A54FCFA1B8AD1201801136DD@ENI-MAIL.eclipse-networks.com> <00DB2AB2-2219-4C0D-8AA3-F7F58023C4E0@corp.arin.net> <8F732664-2F0A-4030-B32A-F5801F5F18DA@arin.net> <65F58738-8342-4BF0-8D1A-DF0AE7E7EC97@arin.net> Message-ID: On Wed, May 27, 2015 at 2:06 PM, John Curran wrote: > If the community cannot come together in consensus on globally coordinated > policy, then your observation about the present state being worse than a global > policy approach doesn?t really matter, and you can disregard my note. Ha! Fair point. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jschiller at google.com Wed May 27 15:27:57 2015 From: jschiller at google.com (Jason Schiller) Date: Wed, 27 May 2015 15:27:57 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: Owen, I am trying to understand your suggestion... is it: Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Date: 26 May 2015 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 4, 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. This restriction does not include M&A transfers. This restriction does not include a transfer to a wholly owned subsidiary out side of the ARIN service region if the recipient org will be required to not transfer the IP space for the remaining balance of 12 month window." Comments: 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; 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. In addition this will not affect the assignments and allocations issued by ARIN they will still be subject to the 12 month restriction. a. Timetable for implementation: Immediate b. Anything else On Wed, May 27, 2015 at 8:03 AM, Owen DeLong wrote: > I could support a policy that allows you to transfer them to your own entity out of region for this purpose if there were some language that prevented subsequent flipping. > > However, the policy as proposed creates too much opportunity for unintended consequences that the original anti-flip language is intended to prevent. > > Owen > >> On May 26, 2015, at 10:30 PM, David Huberman wrote: >> >>> Why is another region's policy problem or restrictions something that needs >>> fixing through ARIN policy? >> >> Two answers: >> >> Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed. >> AND >> Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request. >> >> _______________________________________________ >> 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. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 From owen at delong.com Wed May 27 23:24:17 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 28 May 2015 05:24:17 +0200 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: <9C0B700D-2609-4A80-9F09-0FA396EBEBA4@delong.com> Would simply changing 30 days to 90 days be sufficient to address the issues being raised? Owen > On May 27, 2015, at 6:57 PM, Jason Schiller wrote: > > Under the 25% utilization across all assignments held, an end site with a /24 with 253 hosts, a router, network and broadcast would be 100% utilized. They could then waive their hands and say something about growth, and double to a /23 (total) at 50% utilized, and double again to a /22 (total) at 25% utilization? > > My impression of the 25% requirement is to have some real world measure to off set a pure future looking indisputable claim. > > My example attempted to replace the real world measure with some real commitment to have in process things that need IPs that can be counted (but won't necessarily have the IP in service in 30 days). > > I don't know how you avoid hand wavyness for initial allocation, or make slow start work in a transfer world. > > ___Jason > >> On Wed, May 27, 2015 at 11:43 AM, William Herrin wrote: >> On Wed, May 27, 2015 at 11:04 AM, Jason Schiller wrote: >> > Imagine a case were an end user has a real commitment to deploy five new >> > offices each with ~210 employees (each employee with a single desktop) over >> > the next quarter. Office space is leased, computers are bought, >> > construction is on going for all five sites, and one site is scheduled to go >> > live in 45 days, 250 offers have been extended for the first site, 50 have >> > accepted, another 200 candidates are in the interview pipeline for the other >> > two sites with a scheduled go live date in the next 60 days. >> > >> > Based on this growth rate, it is likely that 20 sites with approximately 210 >> > employees (and desktops) each will be deployed in the next 12 months. >> > >> > It is anticipated that it will take 45 days to get the 210 computers at the >> > new site physically setup on desks, and connected to a working LAN, with >> > working Internet access. >> > >> > The organization has on hand enough equipment to number 82% of five /24s. >> > With a real one year projection based on past growth for filling 82% of >> > twenty /24s over the next year. >> > >> > One would think this should be sufficient justification for at least a /21 >> > (five /24s round up to eight /24s or a /21) with a real commitment already >> > underway to use these addresses. Once in service more than 50% of a /21 >> > will be in use. >> > >> > There are also a projection for a total of twenty /24s at 82% utilization or >> > 51% of >> > /19 over the next year. >> > >> > This sounds like it should be a good justification for a /20 or a /19. >> > >> > I think the 25% requirement in 30 days is unreasonable, especially when an >> > organization is already committed but the work will take longer than 30 >> > days. But 50% of a purely future looking projection is not strong enough. >> >> Hi Jason, >> >> For the sake of the argument, I accept your example in whole. >> >> That organization did not appear out of thin air, suddenly hire up >> hundreds of staff and build a bunch of locations. Large organizations >> don't magically spring into being. They already had a substantial >> operation and its infrastructure. Changing the 25% 30-day requirement >> to apply in aggregate across all direct assignments held by the >> organization would resolve the problem here quite effectively. >> >> I also note that the office space is leased and being paid for while >> construction is ongoing. Given the lead time for data circuits, are >> not those contracts let as well? >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Owner, Dirtside Systems ......... Web: > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > _______________________________________________ > 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 owen at delong.com Wed May 27 23:39:56 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 28 May 2015 05:39:56 +0200 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. Owen > On May 27, 2015, at 9:27 PM, Jason Schiller wrote: > > Owen, > > I am trying to understand your suggestion... is it: > > Draft Policy ARIN-2015-2 > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > Date: 26 May 2015 > > 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 4, 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. > This restriction does not include M&A transfers. > This restriction does not include a transfer to a wholly owned > subsidiary out side of the ARIN service region > if the recipient org will be required to not transfer the IP space > for the remaining balance of 12 month window." > > Comments: > > 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; 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. In addition this will not > affect the assignments and allocations issued by ARIN they will still > be subject to the 12 month restriction. > > a. Timetable for implementation: Immediate > > b. Anything else > >> On Wed, May 27, 2015 at 8:03 AM, Owen DeLong wrote: >> I could support a policy that allows you to transfer them to your own entity out of region for this purpose if there were some language that prevented subsequent flipping. >> >> However, the policy as proposed creates too much opportunity for unintended consequences that the original anti-flip language is intended to prevent. >> >> Owen >> >>>> On May 26, 2015, at 10:30 PM, David Huberman wrote: >>>> >>>> Why is another region's policy problem or restrictions something that needs >>>> fixing through ARIN policy? >>> >>> Two answers: >>> >>> Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed. >>> AND >>> Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request. >>> >>> _______________________________________________ >>> 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. > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 From David.Huberman at microsoft.com Wed May 27 23:44:21 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 28 May 2015 03:44:21 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: <9C0B700D-2609-4A80-9F09-0FA396EBEBA4@delong.com> References: <5564C252.4060904@arin.net> <9C0B700D-2609-4A80-9F09-0FA396EBEBA4@delong.com> Message-ID: It might be, except there is another strong scenario discussed in the original policy text. End-users are subject to this text for ADDITIONAL assignments. Policy only requires 80% overall utilization of existing addresses. You?d (often) continue to use existing space to 100% before you?d open up the new block. It maximizes clean summarization opportunities. If you properly manage your address space, you may very well not meet the 25% in 90 days requirement. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, May 27, 2015 8:24 PM To: Jason Schiller Cc: ARIN PPML (ppml at arin.net) Subject: Re: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Would simply changing 30 days to 90 days be sufficient to address the issues being raised? Owen On May 27, 2015, at 6:57 PM, Jason Schiller > wrote: Under the 25% utilization across all assignments held, an end site with a /24 with 253 hosts, a router, network and broadcast would be 100% utilized. They could then waive their hands and say something about growth, and double to a /23 (total) at 50% utilized, and double again to a /22 (total) at 25% utilization? My impression of the 25% requirement is to have some real world measure to off set a pure future looking indisputable claim. My example attempted to replace the real world measure with some real commitment to have in process things that need IPs that can be counted (but won't necessarily have the IP in service in 30 days). I don't know how you avoid hand wavyness for initial allocation, or make slow start work in a transfer world. ___Jason On Wed, May 27, 2015 at 11:43 AM, William Herrin > wrote: On Wed, May 27, 2015 at 11:04 AM, Jason Schiller > wrote: > Imagine a case were an end user has a real commitment to deploy five new > offices each with ~210 employees (each employee with a single desktop) over > the next quarter. Office space is leased, computers are bought, > construction is on going for all five sites, and one site is scheduled to go > live in 45 days, 250 offers have been extended for the first site, 50 have > accepted, another 200 candidates are in the interview pipeline for the other > two sites with a scheduled go live date in the next 60 days. > > Based on this growth rate, it is likely that 20 sites with approximately 210 > employees (and desktops) each will be deployed in the next 12 months. > > It is anticipated that it will take 45 days to get the 210 computers at the > new site physically setup on desks, and connected to a working LAN, with > working Internet access. > > The organization has on hand enough equipment to number 82% of five /24s. > With a real one year projection based on past growth for filling 82% of > twenty /24s over the next year. > > One would think this should be sufficient justification for at least a /21 > (five /24s round up to eight /24s or a /21) with a real commitment already > underway to use these addresses. Once in service more than 50% of a /21 > will be in use. > > There are also a projection for a total of twenty /24s at 82% utilization or > 51% of > /19 over the next year. > > This sounds like it should be a good justification for a /20 or a /19. > > I think the 25% requirement in 30 days is unreasonable, especially when an > organization is already committed but the work will take longer than 30 > days. But 50% of a purely future looking projection is not strong enough. Hi Jason, For the sake of the argument, I accept your example in whole. That organization did not appear out of thin air, suddenly hire up hundreds of staff and build a bunch of locations. Large organizations don't magically spring into being. They already had a substantial operation and its infrastructure. Changing the 25% 30-day requirement to apply in aggregate across all direct assignments held by the organization would resolve the problem here quite effectively. I also note that the office space is leased and being paid for while construction is ongoing. Given the lead time for data circuits, are not those contracts let as well? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 _______________________________________________ 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 jcurran at arin.net Thu May 28 07:49:29 2015 From: jcurran at arin.net (John Curran) Date: Thu, 28 May 2015 11:49:29 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > > My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. > > So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. That second portion that you seek would affect the ongoing operation of another RIR, i.e. it requires them having some explicit policy to that effect. To obtain the result you seek, we either need globally coordinated transfer policy in this area, or you need to make the inter-RIR transfer policy explicit in this regard in determination of compatibility. /John John Curran President and CEO ARIN From David.Huberman at microsoft.com Thu May 28 07:58:52 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 28 May 2015 11:58:52 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> , <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> Message-ID: I've attended ARIN, RIPE, and LACNIC in the last few weeks and I think that there is significant support for the idea of trying to craft a global policy on inter-RIR transfers. ________________________________________ From: arin-ppml-bounces at arin.net on behalf of John Curran Sent: Thursday, May 28, 2015 4:49:29 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > > My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. > > So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. That second portion that you seek would affect the ongoing operation of another RIR, i.e. it requires them having some explicit policy to that effect. To obtain the result you seek, we either need globally coordinated transfer policy in this area, or you need to make the inter-RIR transfer policy explicit in this regard in determination of compatibility. /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Thu May 28 08:27:22 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 28 May 2015 14:27:22 +0200 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> Message-ID: <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> Or simply not permit it under ARIN policy until such exists. Owen > On May 28, 2015, at 1:49 PM, John Curran wrote: > > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. > > That second portion that you seek would affect the ongoing operation of > another RIR, i.e. it requires them having some explicit policy to that effect. > > To obtain the result you seek, we either need globally coordinated transfer > policy in this area, or you need to make the inter-RIR transfer policy explicit > in this regard in determination of compatibility. > > /John > > John Curran > President and CEO > ARIN > > > > From jschiller at google.com Thu May 28 09:46:55 2015 From: jschiller at google.com (Jason Schiller) Date: Thu, 28 May 2015 09:46:55 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> Message-ID: Owen, How does that differ from the policy text I sent? Can you send an idea of policy text? I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. ___Jason On May 28, 2015 8:31 AM, "Owen DeLong" wrote: > Or simply not permit it under ARIN policy until such exists. > > Owen > > > On May 28, 2015, at 1:49 PM, John Curran wrote: > > > > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > >> > >> My suggestion is that I don't mind (virtually) unrestricted moves of > addresses to different regions staying with the same organization. However, > if we are to allow that, I want us to find a way that you can't merely use > that as a way to move addresses out of flip protection to then flip them to > another organization via an RIR with a less restrictive transfer policy. > >> > >> So... If you transfer addresses to another region, keeping them in the > same organization, no penalty. However, you are not allowed to subsequently > transfer them (or other addresses in that region) to an external party for > at least 12 months. > > > > That second portion that you seek would affect the ongoing operation of > > another RIR, i.e. it requires them having some explicit policy to that > effect. > > > > To obtain the result you seek, we either need globally coordinated > transfer > > policy in this area, or you need to make the inter-RIR transfer policy > explicit > > in this regard in determination of compatibility. > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JOHN at egh.com Thu May 28 11:26:23 2015 From: JOHN at egh.com (John Santos) Date: Thu, 28 May 2015 11:26:23 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> Message-ID: <1150528104822.28183B-100000@joonya.egh.com> On Thu, 28 May 2015, John Curran wrote: > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > > > > My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses o > ut of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. > > > > So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. > > That second portion that you seek would affect the ongoing operation of > another RIR, i.e. it requires them having some explicit policy to that effect. > > To obtain the result you seek, we either need globally coordinated transfer > policy in this area, or you need to make the inter-RIR transfer policy explicit > in this regard in determination of compatibility. If the penalty were that if you transfered out of your organization those addresses in less than 12 months, you could not receive new addresses (either from free pool or as the result of a directed transfer) UNDER ARIN until the 12 months were up, there would be no requirement of any change to any other RIR's rules nor any requirement of coordination with other RIRs. This could be handled under needs assessment. When a recipient comes to ARIN saying they need X addresses and currently have less than Y% available from our current total of Z addresses, ARIN would count addresses transfered out within the last 12 months as still being included in Z. Addresses transfered to another RIR and then out of the org would prevent the recipient from returning to the well repeatedly. But an org that messed up its planning once, got too many addresses and then decided to sell them would be okay. If they messed up twice (announce need in January and acquire addresses, decide in Feb that they don't really need them any more due to changed business plans or conditions and sell them, then turn around again in March to get more addresses) they would either be utterly incompetent, having screwed up their planning 3 times in a year, or they would be trying to game the system and their business plan is to flip addresses, not to provide an Internet service. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at arin.net Thu May 28 12:25:05 2015 From: jcurran at arin.net (John Curran) Date: Thu, 28 May 2015 16:25:05 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <1150528104822.28183B-100000@joonya.egh.com> References: <1150528104822.28183B-100000@joonya.egh.com> Message-ID: <5C2C78C5-44A5-4127-BFF2-D251C42F3186@corp.arin.net> > On May 28, 2015, at 11:26 AM, John Santos wrote: > > If the penalty were that if you transfered out of your organization those > addresses in less than 12 months, you could not receive new addresses > (either from free pool or as the result of a directed transfer) UNDER ARIN > until the 12 months were up, there would be no requirement of any change > to any other RIR's rules nor any requirement of coordination with other > RIRs. That is correct - in Owen?s example, it was the proposed requirement that the recipient organization in another region would be be prohibited from any future transfers in that region that results in a need for coordinated policy. /John John Curran President and CEO ARIN From rudi.daniel at gmail.com Thu May 28 12:29:24 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 28 May 2015 12:29:24 -0400 Subject: [arin-ppml] 2015-2 Message-ID: <<<"I've attended ARIN, RIPE, and LACNIC in the last few weeks and I think that there is significant support for the idea of trying to craft a global policy on inter-RIR transfers.">>> I would support the crafting of such a policy for IPv4. I don't hear the requirement for IPv6. But what would it mean down line if there were no such global policy? RD On May 28, 2015 12:00 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (John Curran) > 2. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR > Transfers > to Specified Recipients) (David Huberman) > 3. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Owen DeLong) > 4. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Jason Schiller) > 5. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (John Santos) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 May 2015 11:49:29 +0000 > From: John Curran > To: Owen DeLong > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267 at corp.arin.net> > Content-Type: text/plain; charset="us-ascii" > > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > > > > My suggestion is that I don't mind (virtually) unrestricted moves of > addresses to different regions staying with the same organization. However, > if we are to allow that, I want us to find a way that you can't merely use > that as a way to move addresses out of flip protection to then flip them to > another organization via an RIR with a less restrictive transfer policy. > > > > So... If you transfer addresses to another region, keeping them in the > same organization, no penalty. However, you are not allowed to subsequently > transfer them (or other addresses in that region) to an external party for > at least 12 months. > > That second portion that you seek would affect the ongoing operation of > another RIR, i.e. it requires them having some explicit policy to that > effect. > > To obtain the result you seek, we either need globally coordinated transfer > policy in this area, or you need to make the inter-RIR transfer policy > explicit > in this regard in determination of compatibility. > > /John > > John Curran > President and CEO > ARIN > > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 28 May 2015 11:58:52 +0000 > From: David Huberman > To: John Curran , Owen DeLong > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: > < > DM2PR03MB39841219CDC3FC02405B6949BCA0 at DM2PR03MB398.namprd03.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > I've attended ARIN, RIPE, and LACNIC in the last few weeks and I think > that there is significant support for the idea of trying to craft a global > policy on inter-RIR transfers. > > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf > of John Curran > Sent: Thursday, May 28, 2015 4:49:29 AM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > > > > My suggestion is that I don't mind (virtually) unrestricted moves of > addresses to different regions staying with the same organization. However, > if we are to allow that, I want us to find a way that you can't merely use > that as a way to move addresses out of flip protection to then flip them to > another organization via an RIR with a less restrictive transfer policy. > > > > So... If you transfer addresses to another region, keeping them in the > same organization, no penalty. However, you are not allowed to subsequently > transfer them (or other addresses in that region) to an external party for > at least 12 months. > > That second portion that you seek would affect the ongoing operation of > another RIR, i.e. it requires them having some explicit policy to that > effect. > > To obtain the result you seek, we either need globally coordinated transfer > policy in this area, or you need to make the inter-RIR transfer policy > explicit > in this regard in determination of compatibility. > > /John > > John Curran > President and CEO > ARIN > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > ------------------------------ > > Message: 3 > Date: Thu, 28 May 2015 14:27:22 +0200 > From: Owen DeLong > To: John Curran > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <4023727F-EF91-4BED-A2EC-E00CFA55707E at delong.com> > Content-Type: text/plain; charset=us-ascii > > Or simply not permit it under ARIN policy until such exists. > > Owen > > > On May 28, 2015, at 1:49 PM, John Curran wrote: > > > > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > >> > >> My suggestion is that I don't mind (virtually) unrestricted moves of > addresses to different regions staying with the same organization. However, > if we are to allow that, I want us to find a way that you can't merely use > that as a way to move addresses out of flip protection to then flip them to > another organization via an RIR with a less restrictive transfer policy. > >> > >> So... If you transfer addresses to another region, keeping them in the > same organization, no penalty. However, you are not allowed to subsequently > transfer them (or other addresses in that region) to an external party for > at least 12 months. > > > > That second portion that you seek would affect the ongoing operation of > > another RIR, i.e. it requires them having some explicit policy to that > effect. > > > > To obtain the result you seek, we either need globally coordinated > transfer > > policy in this area, or you need to make the inter-RIR transfer policy > explicit > > in this regard in determination of compatibility. > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 28 May 2015 09:46:55 -0400 > From: Jason Schiller > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: > < > CAC4yj2VyWuZEQJFKOzC7zy1o3tXvk7JWnK1H95A28kt6XYJ0Og at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Owen, > > How does that differ from the policy text I sent? > > Can you send an idea of policy text? > > I thought the text I sent said that an ARIN org can transfer IPs out to > another wholely owned subsidiary in another RIR region if they have been > the recipient of transfer in less that 12 months IF the recipient org will > be required (read by recipient's RIR policy) to hold the transfered > resource for the balance of the 12 months. > > ___Jason > On May 28, 2015 8:31 AM, "Owen DeLong" wrote: > > > Or simply not permit it under ARIN policy until such exists. > > > > Owen > > > > > On May 28, 2015, at 1:49 PM, John Curran wrote: > > > > > > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > > >> > > >> My suggestion is that I don't mind (virtually) unrestricted moves of > > addresses to different regions staying with the same organization. > However, > > if we are to allow that, I want us to find a way that you can't merely > use > > that as a way to move addresses out of flip protection to then flip them > to > > another organization via an RIR with a less restrictive transfer policy. > > >> > > >> So... If you transfer addresses to another region, keeping them in the > > same organization, no penalty. However, you are not allowed to > subsequently > > transfer them (or other addresses in that region) to an external party > for > > at least 12 months. > > > > > > That second portion that you seek would affect the ongoing operation of > > > another RIR, i.e. it requires them having some explicit policy to that > > effect. > > > > > > To obtain the result you seek, we either need globally coordinated > > transfer > > > policy in this area, or you need to make the inter-RIR transfer policy > > explicit > > > in this regard in determination of compatibility. > > > > > > /John > > > > > > John Curran > > > President and CEO > > > ARIN > > > > > > > > > > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20150528/ec1fba87/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Thu, 28 May 2015 11:26:23 -0400 > From: John Santos > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <1150528104822.28183B-100000 at joonya.egh.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 28 May 2015, John Curran wrote: > > > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: > > > > > > My suggestion is that I don't mind (virtually) unrestricted moves of > addresses to different regions staying with the same organization. However, > if we are to allow that, I want us to find a way that you can't merely use > that as a way to move addresses o > > ut of flip protection to then flip them to another organization via an > RIR with a less restrictive transfer policy. > > > > > > So... If you transfer addresses to another region, keeping them in the > same organization, no penalty. However, you are not allowed to subsequently > transfer them (or other addresses in that region) to an external party for > at least 12 months. > > > > That second portion that you seek would affect the ongoing operation of > > another RIR, i.e. it requires them having some explicit policy to that > effect. > > > > To obtain the result you seek, we either need globally coordinated > transfer > > policy in this area, or you need to make the inter-RIR transfer policy > explicit > > in this regard in determination of compatibility. > > If the penalty were that if you transfered out of your organization those > addresses in less than 12 months, you could not receive new addresses > (either from free pool or as the result of a directed transfer) UNDER ARIN > until the 12 months were up, there would be no requirement of any change > to any other RIR's rules nor any requirement of coordination with other > RIRs. > > This could be handled under needs assessment. When a recipient comes to > ARIN saying they need X addresses and currently have less than Y% > available from our current total of Z addresses, ARIN would count > addresses transfered out within the last 12 months as still being > included in Z. Addresses transfered to another RIR and then out of > the org would prevent the recipient from returning to the well > repeatedly. But an org that messed up its planning once, got too > many addresses and then decided to sell them would be okay. > > If they messed up twice (announce need in January and acquire addresses, > decide in Feb that they don't really need them any more due to changed > business plans or conditions and sell them, then turn around again in > March to get more addresses) they would either be utterly incompetent, > having screwed up their planning 3 times in a year, or they would be > trying to game the system and their business plan is to flip addresses, > not to provide an Internet service. > > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 119, Issue 18 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Thu May 28 12:34:43 2015 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 May 2015 09:34:43 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> Message-ID: <556743A3.8020809@ipinc.net> How about we permit it only to orgs that can demonstrate the existence and adherence to an IPv6 migration plan? Ted On 5/28/2015 5:27 AM, Owen DeLong wrote: > Or simply not permit it under ARIN policy until such exists. > > Owen > >> On May 28, 2015, at 1:49 PM, John Curran wrote: >> >> On May 27, 2015, at 11:39 PM, Owen DeLong wrote: >>> >>> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >>> >>> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >> >> That second portion that you seek would affect the ongoing operation of >> another RIR, i.e. it requires them having some explicit policy to that effect. >> >> To obtain the result you seek, we either need globally coordinated transfer >> policy in this area, or you need to make the inter-RIR transfer policy explicit >> in this regard in determination of compatibility. >> >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From hannigan at gmail.com Thu May 28 12:36:43 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 28 May 2015 12:36:43 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> Message-ID: <51F36800-345F-4135-84FF-131C031EE954@gmail.com> Why are we still dictating how other regions should operate their RIRs? We can already use our numbers. Best, Martin > On May 28, 2015, at 09:46, Jason Schiller wrote: > > Owen, > > How does that differ from the policy text I sent? > > Can you send an idea of policy text? > > I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. > > ___Jason > >> On May 28, 2015 8:31 AM, "Owen DeLong" wrote: >> Or simply not permit it under ARIN policy until such exists. >> >> Owen >> >> > On May 28, 2015, at 1:49 PM, John Curran wrote: >> > >> > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: >> >> >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >> >> >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >> > >> > That second portion that you seek would affect the ongoing operation of >> > another RIR, i.e. it requires them having some explicit policy to that effect. >> > >> > To obtain the result you seek, we either need globally coordinated transfer >> > policy in this area, or you need to make the inter-RIR transfer policy explicit >> > in this regard in determination of compatibility. >> > >> > /John >> > >> > John Curran >> > President and CEO >> > ARIN >> > >> > >> > >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu May 28 15:22:23 2015 From: bill at herrin.us (William Herrin) Date: Thu, 28 May 2015 15:22:23 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: On Wed, May 27, 2015 at 12:57 PM, Jason Schiller wrote: > Under the 25% utilization across all assignments held, an end site with a > /24 with 253 hosts, a router, network and broadcast would be 100% utilized. > They could then waive their hands and say something about growth, and double > to a /23 (total) at 50% utilized, and double again to a /22 (total) at 25% > utilization? Hi Jason, Is that a problem? The organization would still have to meet the one-year 50% requirement for the new assignment. Only the 30-day 25% requirement would be spread. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From narten at us.ibm.com Fri May 29 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 29 May 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201505290453.t4T4r2RZ004686@rotala.raleigh.ibm.com> Total of 61 messages in the last 7 days. script run at: Fri May 29 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.95% | 14 | 15.99% | 92523 | bill at herrin.us 11.48% | 7 | 14.91% | 86258 | david.huberman at microsoft.com 9.84% | 6 | 9.89% | 57208 | owen at delong.com 9.84% | 6 | 8.27% | 47844 | jcurran at arin.net 3.28% | 2 | 13.60% | 78728 | rudi.daniel at gmail.com 9.84% | 6 | 6.31% | 36506 | sethm at rollernet.us 6.56% | 4 | 9.10% | 52665 | jschiller at google.com 6.56% | 4 | 4.75% | 27493 | info at arin.net 3.28% | 2 | 3.14% | 18168 | athompso at athompso.net 1.64% | 1 | 2.24% | 12985 | hannigan at gmail.com 1.64% | 1 | 1.60% | 9245 | scottleibrand at gmail.com 1.64% | 1 | 1.57% | 9060 | matthew at matthew.at 1.64% | 1 | 1.42% | 8203 | farmer at umn.edu 1.64% | 1 | 1.26% | 7297 | john at egh.com 1.64% | 1 | 1.24% | 7204 | tedm at ipinc.net 1.64% | 1 | 1.23% | 7139 | sryerse at eclipse-networks.com 1.64% | 1 | 1.17% | 6795 | kevinb at thewire.ca 1.64% | 1 | 1.16% | 6687 | jlewis at lewis.org 1.64% | 1 | 1.15% | 6679 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 61 |100.00% | 578687 | Total From owen at delong.com Fri May 29 03:53:18 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 00:53:18 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <1150528104822.28183B-100000@joonya.egh.com> References: <1150528104822.28183B-100000@joonya.egh.com> Message-ID: <28B17753-23A5-4008-8D85-0F8B9192A7B0@delong.com> > On May 28, 2015, at 8:26 AM, John Santos wrote: > > On Thu, 28 May 2015, John Curran wrote: > >> On May 27, 2015, at 11:39 PM, Owen DeLong wrote: >>> >>> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses o >> ut of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >>> >>> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >> >> That second portion that you seek would affect the ongoing operation of >> another RIR, i.e. it requires them having some explicit policy to that effect. >> >> To obtain the result you seek, we either need globally coordinated transfer >> policy in this area, or you need to make the inter-RIR transfer policy explicit >> in this regard in determination of compatibility. > > If the penalty were that if you transfered out of your organization those > addresses in less than 12 months, you could not receive new addresses > (either from free pool or as the result of a directed transfer) UNDER ARIN > until the 12 months were up, there would be no requirement of any change > to any other RIR's rules nor any requirement of coordination with other > RIRs. I also don?t think it would be sufficient penalty. The company in question would merely obtain their addresses via transfer into another RIR. Owen From owen at delong.com Fri May 29 04:06:32 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 01:06:32 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> Message-ID: > On May 28, 2015, at 6:46 AM, Jason Schiller wrote: > > Owen, > > How does that differ from the policy text I sent? > > Can you send an idea of policy text? > > I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. > > Your proposal allows substitution. ARIN->Other RIR space A Space B Other RIR-> Money/etc. I want to see substitution transfers prohibited. Owen > ___Jason > > On May 28, 2015 8:31 AM, "Owen DeLong" > wrote: > Or simply not permit it under ARIN policy until such exists. > > Owen > > > On May 28, 2015, at 1:49 PM, John Curran > wrote: > > > > On May 27, 2015, at 11:39 PM, Owen DeLong > wrote: > >> > >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. > >> > >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. > > > > That second portion that you seek would affect the ongoing operation of > > another RIR, i.e. it requires them having some explicit policy to that effect. > > > > To obtain the result you seek, we either need globally coordinated transfer > > policy in this area, or you need to make the inter-RIR transfer policy explicit > > in this regard in determination of compatibility. > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Fri May 29 11:13:48 2015 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 29 May 2015 15:13:48 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564D9D4.3030003@rollernet.us> References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> Message-ID: > -----Original Message----- > If I am to take an ARIN centric approach I have to ask why I should care > about problems in other regions that sound like they could solved by > requesting resources from that region. Why would you take an ARIN-centric approach? How about an Internet-centric approach? How about an efficiency-centric or public interest-centric approach? Isn't it more efficient - both for the public and for the affected companies - for legitimate holders of numbers to be able to move resources to wherever they are most needed? --MM From bill at herrin.us Fri May 29 13:08:24 2015 From: bill at herrin.us (William Herrin) Date: Fri, 29 May 2015 13:08:24 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> Message-ID: On Fri, May 29, 2015 at 11:13 AM, Milton L Mueller wrote: > Why would you take an ARIN-centric approach? How about an Internet-centric approach? How about an efficiency-centric or public interest-centric approach? > > Isn't it more efficient - both for the public and for the affected companies - for legitimate holders of numbers to be able to move resources to wherever they are most needed? Only if it can be done without loopholes, corruption and gamesmanship. That would require a global approach not just to transfer policies but to the free pools and IPv4 addressing policy overall. Convert ARIN to truly be the "administrative convenience" John describes, an organization which adheres to external policies rather than making its own. I can't begin to imagine a transfer-only approach to globalizing address management which would not lead pretty directly to practices a reasonable outside observer would consider corrupt. Certainly the one on the table is unclean. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jschiller at google.com Fri May 29 15:06:17 2015 From: jschiller at google.com (Jason Schiller) Date: Fri, 29 May 2015 15:06:17 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> Message-ID: Owen, So does this text cover your proposal then? Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Date: 26 May 2015 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 4, 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. - This restriction does not include M&A transfers. - This restriction does not include a transfer to a wholly owned subsidiary out side of the ARIN service region if the recipient org will be required to not transfer any IP space for the remaining balance of 12 month window." On Fri, May 29, 2015 at 4:06 AM, Owen DeLong wrote: > > On May 28, 2015, at 6:46 AM, Jason Schiller wrote: > > Owen, > > How does that differ from the policy text I sent? > > Can you send an idea of policy text? > > I thought the text I sent said that an ARIN org can transfer IPs out to > another wholely owned subsidiary in another RIR region if they have been > the recipient of transfer in less that 12 months IF the recipient org will > be required (read by recipient's RIR policy) to hold the transfered > resource for the balance of the 12 months. > > Your proposal allows substitution. > > ARIN->Other RIR space A > Space B Other RIR-> Money/etc. > > I want to see substitution transfers prohibited. > > Owen > > ___Jason > On May 28, 2015 8:31 AM, "Owen DeLong" wrote: > >> Or simply not permit it under ARIN policy until such exists. >> >> Owen >> >> > On May 28, 2015, at 1:49 PM, John Curran wrote: >> > >> > On May 27, 2015, at 11:39 PM, Owen DeLong wrote: >> >> >> >> My suggestion is that I don't mind (virtually) unrestricted moves of >> addresses to different regions staying with the same organization. However, >> if we are to allow that, I want us to find a way that you can't merely use >> that as a way to move addresses out of flip protection to then flip them to >> another organization via an RIR with a less restrictive transfer policy. >> >> >> >> So... If you transfer addresses to another region, keeping them in the >> same organization, no penalty. However, you are not allowed to subsequently >> transfer them (or other addresses in that region) to an external party for >> at least 12 months. >> > >> > That second portion that you seek would affect the ongoing operation of >> > another RIR, i.e. it requires them having some explicit policy to that >> effect. >> > >> > To obtain the result you seek, we either need globally coordinated >> transfer >> > policy in this area, or you need to make the inter-RIR transfer policy >> explicit >> > in this regard in determination of compatibility. >> > >> > /John >> > >> > John Curran >> > President and CEO >> > ARIN >> > >> > >> > >> > >> >> > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Fri May 29 16:27:02 2015 From: jschiller at google.com (Jason Schiller) Date: Fri, 29 May 2015 16:27:02 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: Bill, I'm not sure. WRT ISPs there is (at least until depletion happens) slow start, so you get a small chunk, use it up and come back... Once you have a one year history of growth, you can use that past year's growth as a measure of justified need for the next quarter from ARIN or next two years from the market. In that case future need is based on real demonstrated past need. WRT endusers it is completely a future looking projection. Which makes me think hand waving, indisputable projections, and ARIN not in a position to dispute the viability of a business case. The 25% in 30 days is demonstration of real need (not a projection) with a short enough horizon that it feels like ARIN could do something about a request that was pure smoke. The problem is larger deployment just don't move that quickly. One could have a medium sized network, and a need to number out of PA space, but unable to renumber 25% of the network in 30 days. I would a real inventory of real equipment that needs addressing should be sufficient. Removing the 25% / 30 day requirement without some added test based on a current or past measure of need to deflate a purely future looking projection seems too liberal. __Jason On Thu, May 28, 2015 at 3:22 PM, William Herrin wrote: > On Wed, May 27, 2015 at 12:57 PM, Jason Schiller > wrote: > > Under the 25% utilization across all assignments held, an end site with a > > /24 with 253 hosts, a router, network and broadcast would be 100% > utilized. > > They could then waive their hands and say something about growth, and > double > > to a /23 (total) at 50% utilized, and double again to a /22 (total) at > 25% > > utilization? > > Hi Jason, > > Is that a problem? The organization would still have to meet the > one-year 50% requirement for the new assignment. Only the 30-day 25% > requirement would be spread. > > Regards, > Bill Herrin > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri May 29 21:01:10 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 18:01:10 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <5564D9D4.3030003@rollernet.us> Message-ID: > On May 29, 2015, at 8:13 AM, Milton L Mueller wrote: > > > >> -----Original Message----- >> If I am to take an ARIN centric approach I have to ask why I should care >> about problems in other regions that sound like they could solved by >> requesting resources from that region. > > Why would you take an ARIN-centric approach? How about an Internet-centric approach? How about an efficiency-centric or public interest-centric approach? > > Isn't it more efficient - both for the public and for the affected companies - for legitimate holders of numbers to be able to move resources to wherever they are most needed? If that is the only effect, sure. On the other hand, it?s contrary to public interest to permit resources to be redistributed on the basis of motivations other than actual operational need. The claim that such would not occur is absurd at best. Owen From owen at delong.com Fri May 29 21:16:34 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 18:16:34 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> <6FDFDCBB-7019-4A42-9A62-CA4BBABCE267@corp.arin.net> <4023727F-EF91-4BED-A2EC-E00CFA55707E@delong.com> Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE@delong.com> If it were enforceable, it would address my concern. The problem is that we are then looking to have an ARIN contract enjoin an action by the organization in another RIR which I am not sure would give us any recourse whatsoever were that contract to be violated. That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so. We?ve already seen that attempting to unilaterally influence minimum policy requirements on other regions is unlikely to work. Witness RIPEs recent ?workaround? to ?compatible needs basis?. I am not especially interested in expanding this problem space. Owen > On May 29, 2015, at 12:06 PM, Jason Schiller wrote: > > Owen, > > So does this text cover your proposal then? > > Draft Policy ARIN-2015-2 > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > Date: 26 May 2015 > > 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 4, 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. > - This restriction does not include M&A transfers. > - This restriction does not include a transfer to a wholly owned > subsidiary out side of the ARIN service region > if the recipient org will be required to not transfer any IP space > for the remaining balance of 12 month window." > > > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong > wrote: > >> On May 28, 2015, at 6:46 AM, Jason Schiller > wrote: >> >> Owen, >> >> How does that differ from the policy text I sent? >> >> Can you send an idea of policy text? >> >> I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. >> >> > Your proposal allows substitution. > > ARIN->Other RIR space A > Space B Other RIR-> Money/etc. > > I want to see substitution transfers prohibited. > > Owen > >> ___Jason >> >> On May 28, 2015 8:31 AM, "Owen DeLong" > wrote: >> Or simply not permit it under ARIN policy until such exists. >> >> Owen >> >> > On May 28, 2015, at 1:49 PM, John Curran > wrote: >> > >> > On May 27, 2015, at 11:39 PM, Owen DeLong > wrote: >> >> >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >> >> >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >> > >> > That second portion that you seek would affect the ongoing operation of >> > another RIR, i.e. it requires them having some explicit policy to that effect. >> > >> > To obtain the result you seek, we either need globally coordinated transfer >> > policy in this area, or you need to make the inter-RIR transfer policy explicit >> > in this regard in determination of compatibility. >> > >> > /John >> > >> > John Curran >> > President and CEO >> > ARIN >> > >> > >> > >> > >> > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com |571-266-0006 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Sat May 30 17:48:47 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sat, 30 May 2015 17:48:47 -0400 Subject: [arin-ppml] ARIN-PPML 2015-2 Message-ID: >>>That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so.<<< Tend to agree ...It may be better addressed at global policy level if at all. RD On May 30, 2015 12:00 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 May 2015 18:16:34 -0700 > From: Owen DeLong > To: Jason Schiller > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE at delong.com> > Content-Type: text/plain; charset="utf-8" > > If it were enforceable, it would address my concern. > > The problem is that we are then looking to have an ARIN contract enjoin an > action by the organization in another RIR which I am not sure would give us > any recourse whatsoever were that contract to be violated. > > That?s why I didn?t propose language? I don?t think the issue in question > can be unilaterally addressed, so I think we should accept that and those > that are interested can begin work on a globally coordinated policy if they > desire to do so. > > We?ve already seen that attempting to unilaterally influence minimum > policy requirements on other regions is unlikely to work. Witness RIPEs > recent ?workaround? to ?compatible needs basis?. I am not especially > interested in expanding this problem space. > > Owen > > > On May 29, 2015, at 12:06 PM, Jason Schiller > wrote: > > > > Owen, > > > > So does this text cover your proposal then? > > > > Draft Policy ARIN-2015-2 > > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > > > Date: 26 May 2015 > > > > 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 4, 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. > > - This restriction does not include M&A transfers. > > - This restriction does not include a transfer to a wholly owned > > subsidiary out side of the ARIN service region > > if the recipient org will be required to not transfer any IP > space > > for the remaining balance of 12 month window." > > > > > > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong owen at delong.com>> wrote: > > > >> On May 28, 2015, at 6:46 AM, Jason Schiller > wrote: > >> > >> Owen, > >> > >> How does that differ from the policy text I sent? > >> > >> Can you send an idea of policy text? > >> > >> I thought the text I sent said that an ARIN org can transfer IPs out to > another wholely owned subsidiary in another RIR region if they have been > the recipient of transfer in less that 12 months IF the recipient org will > be required (read by recipient's RIR policy) to hold the transfered > resource for the balance of the 12 months. > >> > >> > > Your proposal allows substitution. > > > > ARIN->Other RIR space A > > Space B Other RIR-> Money/etc. > > > > I want to see substitution transfers prohibited. > > > > Owen > > > >> ___Jason > >> > >> On May 28, 2015 8:31 AM, "Owen DeLong" owen at delong.com>> wrote: > >> Or simply not permit it under ARIN policy until such exists. > >> > >> Owen > >> > >> > On May 28, 2015, at 1:49 PM, John Curran jcurran at arin.net>> wrote: > >> > > >> > On May 27, 2015, at 11:39 PM, Owen DeLong owen at delong.com>> wrote: > >> >> > >> >> My suggestion is that I don't mind (virtually) unrestricted moves of > addresses to different regions staying with the same organization. However, > if we are to allow that, I want us to find a way that you can't merely use > that as a way to move addresses out of flip protection to then flip them to > another organization via an RIR with a less restrictive transfer policy. > >> >> > >> >> So... If you transfer addresses to another region, keeping them in > the same organization, no penalty. However, you are not allowed to > subsequently transfer them (or other addresses in that region) to an > external party for at least 12 months. > >> > > >> > That second portion that you seek would affect the ongoing operation > of > >> > another RIR, i.e. it requires them having some explicit policy to > that effect. > >> > > >> > To obtain the result you seek, we either need globally coordinated > transfer > >> > policy in this area, or you need to make the inter-RIR transfer > policy explicit > >> > in this regard in determination of compatibility. > >> > > >> > /John > >> > > >> > John Curran > >> > President and CEO > >> > ARIN > >> > > >> > > >> > > >> > > >> > > > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com >|571-266-0006 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20150529/10dd910c/attachment-0001.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 119, Issue 23 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Sun May 31 10:49:14 2015 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 31 May 2015 14:49:14 +0000 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: References: Message-ID: It?s very na?ve for people to suggest that national policy in China is going to be affected by a global policy of RIRs. --MM From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel Sent: Saturday, May 30, 2015 5:49 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-PPML 2015-2 >>>That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so.<<< Tend to agree ...It may be better addressed at global policy level if at all. RD On May 30, 2015 12:00 PM, > wrote: Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) (Owen DeLong) ---------------------------------------------------------------------- Message: 1 Date: Fri, 29 May 2015 18:16:34 -0700 From: Owen DeLong > To: Jason Schiller > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE at delong.com> Content-Type: text/plain; charset="utf-8" If it were enforceable, it would address my concern. The problem is that we are then looking to have an ARIN contract enjoin an action by the organization in another RIR which I am not sure would give us any recourse whatsoever were that contract to be violated. That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so. We?ve already seen that attempting to unilaterally influence minimum policy requirements on other regions is unlikely to work. Witness RIPEs recent ?workaround? to ?compatible needs basis?. I am not especially interested in expanding this problem space. Owen > On May 29, 2015, at 12:06 PM, Jason Schiller > wrote: > > Owen, > > So does this text cover your proposal then? > > Draft Policy ARIN-2015-2 > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > Date: 26 May 2015 > > 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 4, 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. > - This restriction does not include M&A transfers. > - This restriction does not include a transfer to a wholly owned > subsidiary out side of the ARIN service region > if the recipient org will be required to not transfer any IP space > for the remaining balance of 12 month window." > > > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong >> wrote: > >> On May 28, 2015, at 6:46 AM, Jason Schiller >> wrote: >> >> Owen, >> >> How does that differ from the policy text I sent? >> >> Can you send an idea of policy text? >> >> I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. >> >> > Your proposal allows substitution. > > ARIN->Other RIR space A > Space B Other RIR-> Money/etc. > > I want to see substitution transfers prohibited. > > Owen > >> ___Jason >> >> On May 28, 2015 8:31 AM, "Owen DeLong" >> wrote: >> Or simply not permit it under ARIN policy until such exists. >> >> Owen >> >> > On May 28, 2015, at 1:49 PM, John Curran >> wrote: >> > >> > On May 27, 2015, at 11:39 PM, Owen DeLong >> wrote: >> >> >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >> >> >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >> > >> > That second portion that you seek would affect the ongoing operation of >> > another RIR, i.e. it requires them having some explicit policy to that effect. >> > >> > To obtain the result you seek, we either need globally coordinated transfer >> > policy in this area, or you need to make the inter-RIR transfer policy explicit >> > in this regard in determination of compatibility. >> > >> > /John >> > >> > John Curran >> > President and CEO >> > ARIN >> > >> > >> > >> > >> > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com >|571-266-0006 > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 119, Issue 23 ****************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun May 31 14:10:21 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 11:10:21 -0700 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: References: Message-ID: I don?t think anyone has said any such thing, Milton. What we have said is that it seems impossible to allow relaxed inter-RIR transfers within an organization in a way that preserves the anti-flip provisions the community has deemed necessary without having globally coordinated policy for the anti-flip provisions. Whether you support having such a thing or not, that much seems to be simply the facts of the situation. The policy in China is unrelated except to the extent that it was used as an example of a reason that relaxed transfer policy is needed. Owen > On May 31, 2015, at 7:49 AM, Milton L Mueller wrote: > > It?s very na?ve for people to suggest that national policy in China is going to be affected by a global policy of RIRs. > --MM > ? <> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Rudolph Daniel > Sent: Saturday, May 30, 2015 5:49 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML 2015-2 > > >>>That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so.<<< > > Tend to agree ...It may be better addressed at global policy level if at all. > RD > > On May 30, 2015 12:00 PM, > wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 May 2015 18:16:34 -0700 > From: Owen DeLong > > To: Jason Schiller > > Cc: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE at delong.com > > Content-Type: text/plain; charset="utf-8" > > If it were enforceable, it would address my concern. > > The problem is that we are then looking to have an ARIN contract enjoin an action by the organization in another RIR which I am not sure would give us any recourse whatsoever were that contract to be violated. > > That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so. > > We?ve already seen that attempting to unilaterally influence minimum policy requirements on other regions is unlikely to work. Witness RIPEs recent ?workaround? to ?compatible needs basis?. I am not especially interested in expanding this problem space. > > Owen > > > On May 29, 2015, at 12:06 PM, Jason Schiller > wrote: > > > > Owen, > > > > So does this text cover your proposal then? > > > > Draft Policy ARIN-2015-2 > > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > > > Date: 26 May 2015 > > > > 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 4, 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. > > - This restriction does not include M&A transfers. > > - This restriction does not include a transfer to a wholly owned > > subsidiary out side of the ARIN service region > > if the recipient org will be required to not transfer any IP space > > for the remaining balance of 12 month window." > > > > > > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong >> wrote: > > > >> On May 28, 2015, at 6:46 AM, Jason Schiller >> wrote: > >> > >> Owen, > >> > >> How does that differ from the policy text I sent? > >> > >> Can you send an idea of policy text? > >> > >> I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. > >> > >> > > Your proposal allows substitution. > > > > ARIN->Other RIR space A > > Space B Other RIR-> Money/etc. > > > > I want to see substitution transfers prohibited. > > > > Owen > > > >> ___Jason > >> > >> On May 28, 2015 8:31 AM, "Owen DeLong" >> wrote: > >> Or simply not permit it under ARIN policy until such exists. > >> > >> Owen > >> > >> > On May 28, 2015, at 1:49 PM, John Curran >> wrote: > >> > > >> > On May 27, 2015, at 11:39 PM, Owen DeLong >> wrote: > >> >> > >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. > >> >> > >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. > >> > > >> > That second portion that you seek would affect the ongoing operation of > >> > another RIR, i.e. it requires them having some explicit policy to that effect. > >> > > >> > To obtain the result you seek, we either need globally coordinated transfer > >> > policy in this area, or you need to make the inter-RIR transfer policy explicit > >> > in this regard in determination of compatibility. > >> > > >> > /John > >> > > >> > John Curran > >> > President and CEO > >> > ARIN > >> > > >> > > >> > > >> > > >> > > > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com >|571-266-0006 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 119, Issue 23 > ****************************************** > _______________________________________________ > 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 matthew at matthew.at Sun May 31 14:31:38 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 31 May 2015 11:31:38 -0700 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: References: Message-ID: <41E926E1-79E7-4051-B2EC-481980104A51@matthew.at> Anti-flip shouldn't matter the moment there's no free pool left to allocate from. Unless you have some misguided notion that policy hacks are really going to meaningfully impact the full-fledged transfer-only market for v4 space. There's so many ways to structure transactions that policy attempts will be futile. Matthew Kaufman (Sent from my iPhone) > On May 31, 2015, at 11:10 AM, Owen DeLong wrote: > > I don?t think anyone has said any such thing, Milton. > > What we have said is that it seems impossible to allow relaxed inter-RIR transfers within an organization in a way that preserves the anti-flip provisions the community has deemed necessary without having globally coordinated policy for the anti-flip provisions. > > Whether you support having such a thing or not, that much seems to be simply the facts of the situation. > > The policy in China is unrelated except to the extent that it was used as an example of a reason that relaxed transfer policy is needed. > > Owen > >> On May 31, 2015, at 7:49 AM, Milton L Mueller wrote: >> >> It?s very na?ve for people to suggest that national policy in China is going to be affected by a global policy of RIRs. >> --MM >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel >> Sent: Saturday, May 30, 2015 5:49 PM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-PPML 2015-2 >> >> >>>That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so.<<< >> >> Tend to agree ...It may be better addressed at global policy level if at all. >> RD >> >> On May 30, 2015 12:00 PM, wrote: >> Send ARIN-PPML mailing list submissions to >> arin-ppml at arin.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.arin.net/mailman/listinfo/arin-ppml >> or, via email, send a message with subject or body 'help' to >> arin-ppml-request at arin.net >> >> You can reach the person managing the list at >> arin-ppml-owner at arin.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of ARIN-PPML digest..." >> >> >> Today's Topics: >> >> 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers >> to Specified Recipients) (Owen DeLong) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 29 May 2015 18:16:34 -0700 >> From: Owen DeLong >> To: Jason Schiller >> Cc: "arin-ppml at arin.net" >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 >> (Inter-RIR Transfers to Specified Recipients) >> Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE at delong.com> >> Content-Type: text/plain; charset="utf-8" >> >> If it were enforceable, it would address my concern. >> >> The problem is that we are then looking to have an ARIN contract enjoin an action by the organization in another RIR which I am not sure would give us any recourse whatsoever were that contract to be violated. >> >> That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so. >> >> We?ve already seen that attempting to unilaterally influence minimum policy requirements on other regions is unlikely to work. Witness RIPEs recent ?workaround? to ?compatible needs basis?. I am not especially interested in expanding this problem space. >> >> Owen >> >> > On May 29, 2015, at 12:06 PM, Jason Schiller wrote: >> > >> > Owen, >> > >> > So does this text cover your proposal then? >> > >> > Draft Policy ARIN-2015-2 >> > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) >> > >> > Date: 26 May 2015 >> > >> > 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 4, 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. >> > - This restriction does not include M&A transfers. >> > - This restriction does not include a transfer to a wholly owned >> > subsidiary out side of the ARIN service region >> > if the recipient org will be required to not transfer any IP space >> > for the remaining balance of 12 month window." >> > >> > >> > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong > wrote: >> > >> >> On May 28, 2015, at 6:46 AM, Jason Schiller > wrote: >> >> >> >> Owen, >> >> >> >> How does that differ from the policy text I sent? >> >> >> >> Can you send an idea of policy text? >> >> >> >> I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. >> >> >> >> >> > Your proposal allows substitution. >> > >> > ARIN->Other RIR space A >> > Space B Other RIR-> Money/etc. >> > >> > I want to see substitution transfers prohibited. >> > >> > Owen >> > >> >> ___Jason >> >> >> >> On May 28, 2015 8:31 AM, "Owen DeLong" > wrote: >> >> Or simply not permit it under ARIN policy until such exists. >> >> >> >> Owen >> >> >> >> > On May 28, 2015, at 1:49 PM, John Curran > wrote: >> >> > >> >> > On May 27, 2015, at 11:39 PM, Owen DeLong > wrote: >> >> >> >> >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >> >> >> >> >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >> >> > >> >> > That second portion that you seek would affect the ongoing operation of >> >> > another RIR, i.e. it requires them having some explicit policy to that effect. >> >> > >> >> > To obtain the result you seek, we either need globally coordinated transfer >> >> > policy in this area, or you need to make the inter-RIR transfer policy explicit >> >> > in this regard in determination of compatibility. >> >> > >> >> > /John >> >> > >> >> > John Curran >> >> > President and CEO >> >> > ARIN >> >> > >> >> > >> >> > >> >> > >> >> >> > >> > >> > >> > >> > -- >> > _______________________________________________________ >> > Jason Schiller|NetOps|jschiller at google.com |571-266-0006 >> > >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> End of ARIN-PPML Digest, Vol 119, Issue 23 >> ****************************************** >> _______________________________________________ >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun May 31 15:12:52 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 12:12:52 -0700 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: <41E926E1-79E7-4051-B2EC-481980104A51@matthew.at> References: <41E926E1-79E7-4051-B2EC-481980104A51@matthew.at> Message-ID: <17D46C15-AD14-4B1F-86A1-BAF6E99C068A@delong.com> You are free to call it misguided as much as you wish. However, I believe that the notion that turning the RIR system into a collection of auction houses just because the free pool ended is even more misguided, so I guess we should simply agree to disagree about that. Owen > On May 31, 2015, at 11:31 AM, Matthew Kaufman wrote: > > Anti-flip shouldn't matter the moment there's no free pool left to allocate from. > > Unless you have some misguided notion that policy hacks are really going to meaningfully impact the full-fledged transfer-only market for v4 space. There's so many ways to structure transactions that policy attempts will be futile. > > Matthew Kaufman > > (Sent from my iPhone) > > On May 31, 2015, at 11:10 AM, Owen DeLong > wrote: > >> I don?t think anyone has said any such thing, Milton. >> >> What we have said is that it seems impossible to allow relaxed inter-RIR transfers within an organization in a way that preserves the anti-flip provisions the community has deemed necessary without having globally coordinated policy for the anti-flip provisions. >> >> Whether you support having such a thing or not, that much seems to be simply the facts of the situation. >> >> The policy in China is unrelated except to the extent that it was used as an example of a reason that relaxed transfer policy is needed. >> >> Owen >> >>> On May 31, 2015, at 7:49 AM, Milton L Mueller > wrote: >>> >>> It?s very na?ve for people to suggest that national policy in China is going to be affected by a global policy of RIRs. >>> --MM >>> ? <> >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Rudolph Daniel >>> Sent: Saturday, May 30, 2015 5:49 PM >>> To: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] ARIN-PPML 2015-2 >>> >>> >>>That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so.<<< >>> >>> Tend to agree ...It may be better addressed at global policy level if at all. >>> RD >>> >>> On May 30, 2015 12:00 PM, > wrote: >>> Send ARIN-PPML mailing list submissions to >>> arin-ppml at arin.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> or, via email, send a message with subject or body 'help' to >>> arin-ppml-request at arin.net >>> >>> You can reach the person managing the list at >>> arin-ppml-owner at arin.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of ARIN-PPML digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers >>> to Specified Recipients) (Owen DeLong) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Fri, 29 May 2015 18:16:34 -0700 >>> From: Owen DeLong > >>> To: Jason Schiller > >>> Cc: "arin-ppml at arin.net " > >>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 >>> (Inter-RIR Transfers to Specified Recipients) >>> Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE at delong.com > >>> Content-Type: text/plain; charset="utf-8" >>> >>> If it were enforceable, it would address my concern. >>> >>> The problem is that we are then looking to have an ARIN contract enjoin an action by the organization in another RIR which I am not sure would give us any recourse whatsoever were that contract to be violated. >>> >>> That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so. >>> >>> We?ve already seen that attempting to unilaterally influence minimum policy requirements on other regions is unlikely to work. Witness RIPEs recent ?workaround? to ?compatible needs basis?. I am not especially interested in expanding this problem space. >>> >>> Owen >>> >>> > On May 29, 2015, at 12:06 PM, Jason Schiller > wrote: >>> > >>> > Owen, >>> > >>> > So does this text cover your proposal then? >>> > >>> > Draft Policy ARIN-2015-2 >>> > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) >>> > >>> > Date: 26 May 2015 >>> > >>> > 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 4, 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. >>> > - This restriction does not include M&A transfers. >>> > - This restriction does not include a transfer to a wholly owned >>> > subsidiary out side of the ARIN service region >>> > if the recipient org will be required to not transfer any IP space >>> > for the remaining balance of 12 month window." >>> > >>> > >>> > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong >> wrote: >>> > >>> >> On May 28, 2015, at 6:46 AM, Jason Schiller >> wrote: >>> >> >>> >> Owen, >>> >> >>> >> How does that differ from the policy text I sent? >>> >> >>> >> Can you send an idea of policy text? >>> >> >>> >> I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. >>> >> >>> >> >>> > Your proposal allows substitution. >>> > >>> > ARIN->Other RIR space A >>> > Space B Other RIR-> Money/etc. >>> > >>> > I want to see substitution transfers prohibited. >>> > >>> > Owen >>> > >>> >> ___Jason >>> >> >>> >> On May 28, 2015 8:31 AM, "Owen DeLong" >> wrote: >>> >> Or simply not permit it under ARIN policy until such exists. >>> >> >>> >> Owen >>> >> >>> >> > On May 28, 2015, at 1:49 PM, John Curran >> wrote: >>> >> > >>> >> > On May 27, 2015, at 11:39 PM, Owen DeLong >> wrote: >>> >> >> >>> >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >>> >> >> >>> >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >>> >> > >>> >> > That second portion that you seek would affect the ongoing operation of >>> >> > another RIR, i.e. it requires them having some explicit policy to that effect. >>> >> > >>> >> > To obtain the result you seek, we either need globally coordinated transfer >>> >> > policy in this area, or you need to make the inter-RIR transfer policy explicit >>> >> > in this regard in determination of compatibility. >>> >> > >>> >> > /John >>> >> > >>> >> > John Curran >>> >> > President and CEO >>> >> > ARIN >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >>> > >>> > >>> > >>> > >>> > -- >>> > _______________________________________________________ >>> > Jason Schiller|NetOps|jschiller at google.com >|571-266-0006 >>> > >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: > >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> ARIN-PPML mailing list >>> ARIN-PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> >>> End of ARIN-PPML Digest, Vol 119, Issue 23 >>> ****************************************** >>> _______________________________________________ >>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Sun May 31 18:45:14 2015 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 31 May 2015 22:45:14 +0000 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: References: Message-ID: <2078c5d4ff344579a675bc10dd7d27cd@EX13-MBX-13.ad.syr.edu> Owen, I am not buying the argument that this has anything to do with anti-flipping. We are talking about internal transfers ? movement to another arm of the same company. That?s not flipping, that?s moving numbers around the same entity?s network. If people abuse the policy ARIN has the leverage to affect the abusers, and that should be enough. No need for a global policy. From: Owen DeLong [mailto:owen at delong.com] Sent: Sunday, May 31, 2015 2:10 PM To: Milton L Mueller Cc: Rudolph Daniel; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-PPML 2015-2 I don?t think anyone has said any such thing, Milton. What we have said is that it seems impossible to allow relaxed inter-RIR transfers within an organization in a way that preserves the anti-flip provisions the community has deemed necessary without having globally coordinated policy for the anti-flip provisions. Whether you support having such a thing or not, that much seems to be simply the facts of the situation. The policy in China is unrelated except to the extent that it was used as an example of a reason that relaxed transfer policy is needed. Owen On May 31, 2015, at 7:49 AM, Milton L Mueller > wrote: It?s very na?ve for people to suggest that national policy in China is going to be affected by a global policy of RIRs. --MM From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel Sent: Saturday, May 30, 2015 5:49 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-PPML 2015-2 >>>That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so.<<< Tend to agree ...It may be better addressed at global policy level if at all. RD On May 30, 2015 12:00 PM, > wrote: Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) (Owen DeLong) ---------------------------------------------------------------------- Message: 1 Date: Fri, 29 May 2015 18:16:34 -0700 From: Owen DeLong > To: Jason Schiller > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE at delong.com> Content-Type: text/plain; charset="utf-8" If it were enforceable, it would address my concern. The problem is that we are then looking to have an ARIN contract enjoin an action by the organization in another RIR which I am not sure would give us any recourse whatsoever were that contract to be violated. That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so. We?ve already seen that attempting to unilaterally influence minimum policy requirements on other regions is unlikely to work. Witness RIPEs recent ?workaround? to ?compatible needs basis?. I am not especially interested in expanding this problem space. Owen > On May 29, 2015, at 12:06 PM, Jason Schiller > wrote: > > Owen, > > So does this text cover your proposal then? > > Draft Policy ARIN-2015-2 > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > Date: 26 May 2015 > > 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 4, 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. > - This restriction does not include M&A transfers. > - This restriction does not include a transfer to a wholly owned > subsidiary out side of the ARIN service region > if the recipient org will be required to not transfer any IP space > for the remaining balance of 12 month window." > > > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong >> wrote: > >> On May 28, 2015, at 6:46 AM, Jason Schiller >> wrote: >> >> Owen, >> >> How does that differ from the policy text I sent? >> >> Can you send an idea of policy text? >> >> I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. >> >> > Your proposal allows substitution. > > ARIN->Other RIR space A > Space B Other RIR-> Money/etc. > > I want to see substitution transfers prohibited. > > Owen > >> ___Jason >> >> On May 28, 2015 8:31 AM, "Owen DeLong" >> wrote: >> Or simply not permit it under ARIN policy until such exists. >> >> Owen >> >> > On May 28, 2015, at 1:49 PM, John Curran >> wrote: >> > >> > On May 27, 2015, at 11:39 PM, Owen DeLong >> wrote: >> >> >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. >> >> >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. >> > >> > That second portion that you seek would affect the ongoing operation of >> > another RIR, i.e. it requires them having some explicit policy to that effect. >> > >> > To obtain the result you seek, we either need globally coordinated transfer >> > policy in this area, or you need to make the inter-RIR transfer policy explicit >> > in this regard in determination of compatibility. >> > >> > /John >> > >> > John Curran >> > President and CEO >> > ARIN >> > >> > >> > >> > >> > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com >|571-266-0006 > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 119, Issue 23 ****************************************** _______________________________________________ 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 owen at delong.com Sun May 31 21:10:02 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 18:10:02 -0700 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: <2078c5d4ff344579a675bc10dd7d27cd@EX13-MBX-13.ad.syr.edu> References: <2078c5d4ff344579a675bc10dd7d27cd@EX13-MBX-13.ad.syr.edu> Message-ID: <359F49C3-3344-4E5E-A510-31E1DB8CDC70@delong.com> > On May 31, 2015, at 3:45 PM, Milton L Mueller wrote: > > Owen, > I am not buying the argument that this has anything to do with anti-flipping. We are talking about internal transfers ? movement to another arm of the same company. That?s not flipping, that?s moving numbers around the same entity?s network. As stated? The concern is the potential for A->B->Money lather, rinse, repeat. > If people abuse the policy ARIN has the leverage to affect the abusers, and that should be enough. No need for a global policy. ARIN has no leverage once the resources have left the ARIN region, so your argument here is specious at best. Owen > ? <> > From: Owen DeLong [mailto:owen at delong.com ] > Sent: Sunday, May 31, 2015 2:10 PM > To: Milton L Mueller > Cc: Rudolph Daniel; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML 2015-2 > > I don?t think anyone has said any such thing, Milton. > > What we have said is that it seems impossible to allow relaxed inter-RIR transfers within an organization in a way that preserves the anti-flip provisions the community has deemed necessary without having globally coordinated policy for the anti-flip provisions. > > Whether you support having such a thing or not, that much seems to be simply the facts of the situation. > > The policy in China is unrelated except to the extent that it was used as an example of a reason that relaxed transfer policy is needed. > > Owen > > On May 31, 2015, at 7:49 AM, Milton L Mueller > wrote: > > It?s very na?ve for people to suggest that national policy in China is going to be affected by a global policy of RIRs. > --MM > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Rudolph Daniel > Sent: Saturday, May 30, 2015 5:49 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML 2015-2 > > >>>That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so.<<< > Tend to agree ...It may be better addressed at global policy level if at all. > RD > On May 30, 2015 12:00 PM, > wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers > to Specified Recipients) (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 May 2015 18:16:34 -0700 > From: Owen DeLong > > To: Jason Schiller > > Cc: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 > (Inter-RIR Transfers to Specified Recipients) > Message-ID: <8A9F435E-20BF-4E90-9141-99A7D93FC6EE at delong.com > > Content-Type: text/plain; charset="utf-8" > > If it were enforceable, it would address my concern. > > The problem is that we are then looking to have an ARIN contract enjoin an action by the organization in another RIR which I am not sure would give us any recourse whatsoever were that contract to be violated. > > That?s why I didn?t propose language? I don?t think the issue in question can be unilaterally addressed, so I think we should accept that and those that are interested can begin work on a globally coordinated policy if they desire to do so. > > We?ve already seen that attempting to unilaterally influence minimum policy requirements on other regions is unlikely to work. Witness RIPEs recent ?workaround? to ?compatible needs basis?. I am not especially interested in expanding this problem space. > > Owen > > > On May 29, 2015, at 12:06 PM, Jason Schiller > wrote: > > > > Owen, > > > > So does this text cover your proposal then? > > > > Draft Policy ARIN-2015-2 > > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > > > Date: 26 May 2015 > > > > 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 4, 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. > > - This restriction does not include M&A transfers. > > - This restriction does not include a transfer to a wholly owned > > subsidiary out side of the ARIN service region > > if the recipient org will be required to not transfer any IP space > > for the remaining balance of 12 month window." > > > > > > On Fri, May 29, 2015 at 4:06 AM, Owen DeLong >> wrote: > > > >> On May 28, 2015, at 6:46 AM, Jason Schiller >> wrote: > >> > >> Owen, > >> > >> How does that differ from the policy text I sent? > >> > >> Can you send an idea of policy text? > >> > >> I thought the text I sent said that an ARIN org can transfer IPs out to another wholely owned subsidiary in another RIR region if they have been the recipient of transfer in less that 12 months IF the recipient org will be required (read by recipient's RIR policy) to hold the transfered resource for the balance of the 12 months. > >> > >> > > Your proposal allows substitution. > > > > ARIN->Other RIR space A > > Space B Other RIR-> Money/etc. > > > > I want to see substitution transfers prohibited. > > > > Owen > > > >> ___Jason > >> > >> On May 28, 2015 8:31 AM, "Owen DeLong" >> wrote: > >> Or simply not permit it under ARIN policy until such exists. > >> > >> Owen > >> > >> > On May 28, 2015, at 1:49 PM, John Curran >> wrote: > >> > > >> > On May 27, 2015, at 11:39 PM, Owen DeLong >> wrote: > >> >> > >> >> My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy. > >> >> > >> >> So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months. > >> > > >> > That second portion that you seek would affect the ongoing operation of > >> > another RIR, i.e. it requires them having some explicit policy to that effect. > >> > > >> > To obtain the result you seek, we either need globally coordinated transfer > >> > policy in this area, or you need to make the inter-RIR transfer policy explicit > >> > in this regard in determination of compatibility. > >> > > >> > /John > >> > > >> > John Curran > >> > President and CEO > >> > ARIN > >> > > >> > > >> > > >> > > >> > > > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com >|571-266-0006 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 119, Issue 23 > ****************************************** > _______________________________________________ > 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 matthew at matthew.at Sun May 31 22:13:43 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 31 May 2015 19:13:43 -0700 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: <359F49C3-3344-4E5E-A510-31E1DB8CDC70@delong.com> References: <2078c5d4ff344579a675bc10dd7d27cd@EX13-MBX-13.ad.syr.edu> <359F49C3-3344-4E5E-A510-31E1DB8CDC70@delong.com> Message-ID: <556BBFD7.7080804@matthew.at> On 5/31/2015 6:10 PM, Owen DeLong wrote: > >> On May 31, 2015, at 3:45 PM, Milton L Mueller > > wrote: >> >> Owen, >> I am not buying the argument that this has anything to do with >> anti-flipping. We are talking about internal transfers ? movement to >> another arm of the same company. That?s not flipping, that?s moving >> numbers around the same entity?s network. > > As stated? The concern is the potential for A->B->Money lather, rinse, > repeat. > Please explain why this matters one bit after ARIN no longer has a free pool from which the addresses might be coming. I will note that there's really no stopping addresses from being used anywhere by anyone... all we're talking about is whether or not ARIN will be recording this in their database. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Sun May 31 22:21:20 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 31 May 2015 19:21:20 -0700 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: <2078c5d4ff344579a675bc10dd7d27cd@EX13-MBX-13.ad.syr.edu> References: <2078c5d4ff344579a675bc10dd7d27cd@EX13-MBX-13.ad.syr.edu> Message-ID: <556BC1A0.2000305@matthew.at> For the record, I support the policy. The problematic language in the NRPM is this: "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." It means that if I go start a new company, and I buy a big chunk of address space for my existing plans (which meet the 24-month need assessment), and then get a contract that requires that some of that space be registered elsewhere for legal reasons (e.g., China), I need to either A) sit around and not fulfill the contract until the 12 month timer runs out (and hope I have no other reason to acquire addresses on the transfer market in the meantime) or B) buy more addresses that are already in the region I need them to be in, even though I have plenty of addresses in hand already and would rather not buy more addresses than I need. That makes no sense at all. Fixing the policy does. Matthew Kaufman ps. The language also suggests that any time you buy addresses from someone, you should buy a little shell company to go with them so that you can process it as an (exempted) 8.2 transfer.