From info at arin.net Tue Jul 1 12:08:29 2014 From: info at arin.net (ARIN) Date: Tue, 01 Jul 2014 12:08:29 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - June 2014 In-Reply-To: <53A9DC64.7010205@arin.net> References: <53A9DC64.7010205@arin.net> Message-ID: <53B2DCFD.4050802@arin.net> > The AC abandoned ARIN-2014-3, 2014-8 and 2014-11. 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 June 19 meeting have been published: https://www.arin.net/about_us/ac/ac2014_0619.html The petition deadline is 8 July 2014. 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 6/24/14, 4:15 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) met on 19 June 2014. > > The AC recommended the following to the ARIN Board for adoption: > > Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup > > The AC moved the following to last call: > > Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New > Multiple Discrete Networks > Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations > Recommended Draft Policy ARIN-2414-12: Anti-hijack Policy > Recommended Draft Policy ARIN-2014-13: Reduce All Minimum > Allocation/Assignment Units to /24 > > The AC abandoned the following: > > Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 > Block Size Requirements > Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to > Reality of Business > Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal > > The AC provided the following statements: > > "The ARIN council voted to abandon 2014-3 Remove 8.2 and 8.3 and 8.4 > Minimum IPv4 Block Size Requirements for the following reasons: > - Minimal support from the community > - Substantial opposition expressed on list and at the PPM and PPC > The AC recognizes that there was some level of support expressed for a > reduction in the minimum block size requirements, but did not find > enough support to modify this proposal." > > "The ARIN council voted to abandon 2014-8 Alignment of 8.3 Needs > Requirements to Reality of Business: > - The author has confirmed that he was amenable to the abandonment of > the proposal. > - There has been general consensus that this proposal is premature and > makes changes to section 8.3 that could have significant unintentional > policy changes. > - Since the initial proposal a number of other proposals have > addressed many of the concerns." > > "The ARIN council voted to abandon 2014-11 Improved Registry Accuracy > for the following reasons: > - At the PPC staff noted they were working on changes to the RSA/LSRA > that would address many of the issues brought up in the original proposal. > - The community has not supported this proposal on list and at the PPC. > - The proposal would require a significant overhaul to remove out of > scope items that would effectively diminish the proposal." > > The AC abandoned ARIN-2014-3, 2014-8 and 2014-11. 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 > > The AC is continuing to work on the following: > > Draft Policy ARIN-2014-1: Out of Region Use > Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] > Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 > Utilization Requirements > Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers > Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers > Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update > Draft Policy ARIN-2014-17: Change Utilization Requirements from > last-allocation to total-aggregate > > 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 mpetach at netflight.com Tue Jul 1 16:33:50 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 1 Jul 2014 13:33:50 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: On Mon, Jun 30, 2014 at 4:59 PM, Martin Hannigan wrote: > > Scott, > > Asking me to do the work the AC is supposed to do is like asking a nun to > certify their virginity. > In the interests of supporting our community, I volunteer to ... oh, wait. Wrong question. I mean "I support this proposal". Matt > > I made my point and I feel zero need to defend what is completely obvious > and on the record. > > As I explained to our "CEO and President", feel free to demonstrate > otherwise. > > Best, > > Martin > > > > On Jun 30, 2014, at 19:38, Scott Leibrand wrote: > > Martin, > > I felt the objections raised at previous meetings were addressed, not > ignored. Can you clarify how you feel that this policy would make it harder > for a recipient to qualify to receive space via transfer? The intent here > is to allow organizations to create new discrete networks and qualify for > space from them. If you think it will do the opposite, it's worth detailing > how and why. > > It's also worth noting that, by documenting the basic requirements for > such networks, it also reduces ARIN staff's discretion and provides > additional policy certainty. > > Scott > > On Jun 30, 2014, at 3:58 PM, Martin Hannigan wrote: > > Objection, with the majority of the community from the previous ARIN > meeting, recent NANOG PPC and other comments and fora discussion. > > But don't let that stop the ARIN AC from moving it forward in its > obsession with controlling v4 markets. > > Best, > > -M< > > > On Jun 30, 2014, at 17:34, CJ Aronson wrote: > > Hi everyone > > Does anyone have comments on this recommended draft policy? > > Thanks! > ----Cathy > > > On Tue, Jun 24, 2014 at 2:16 PM, ARIN wrote: > >> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to >> send the following to last call: >> >> Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New >> Multiple Discrete Networks >> >> Feedback is encouraged during the last call period. All comments should >> be provided to the Public Policy Mailing List. This last call will >> expire on 8 July 2014. 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-2013-8 >> Subsequent Allocations for New Multiple Discrete Networks >> >> Date: 16 May 2014 >> >> AC's assessment of conformance with the Principles of Internet Number >> Resource Policy: >> >> This proposal enables fair and impartial number resource administration >> by documenting how to get a new block for a new discrete network. Previous >> versions of the policy did have this information and over time it has been >> removed. >> >> This proposal is technically sound. There is a need for discrete networks >> and an organization should have a policy that would allow it to create a >> new discrete network. >> >> This proposal is supported by the community. There has been some concern >> about the criterial that will be used and this version has been updated >> with the current thinking on the criteria. >> >> Policy Statement: >> >> IPv4: >> Add the following statement to section 4.5.4. >> Upon verification that the organization has shown evidence of deployment >> of the new discrete network site, the new network(s) shall be allocated the >> minimum allocation size under section 4.2.1.5 unless the organization can >> demonstrate additional need using the immediate need criteria (4.2.1.6). >> >> IPv6: >> Add an additional reference to section 6.11.5.b such that it references >> both the initial allocation and subsequent allocation sections of the IPv6 >> LIR policy. >> "Each network will be judged against the existing utilization criteria >> specified in 6.5.2 and 6.5.3 as if it were a separate organization..." >> >> Comments: >> a. Timetable for implementation: immediate >> b. This policy is being proposed based upon the Policy Implementation & >> Experience Report from ARIN 32. >> https://www.arin.net/participate/meetings/reports/ >> ARIN_32/PDF/thursday/nobile-policy.pdf >> c: Older versions of the MDN policy did contain new network criteria. >> This criteria appears to have been dropped during subsequent rewrites of >> the MDN policy. "The organization must not allocate a CIDR block larger >> than the current minimum assignment size of the RIR (currently /20 for >> ARIN) to a new network." (https://www.arin.net/policy/ >> archive/nrpm_20041015.pdf) >> _______________________________________________ >> 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. > > > _______________________________________________ > 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 derekc at cnets.net Tue Jul 1 21:10:16 2014 From: derekc at cnets.net (Derek Calanchini) Date: Tue, 01 Jul 2014 18:10:16 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: <53B35BF8.6010908@cnets.net> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cnslogo1.bmp Type: image/bmp Size: 72774 bytes Desc: not available URL: From cja at daydream.com Tue Jul 1 22:38:39 2014 From: cja at daydream.com (Cathy Aronson) Date: Tue, 1 Jul 2014 20:38:39 -0600 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <53B35BF8.6010908@cnets.net> References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> <53B35BF8.6010908@cnets.net> Message-ID: <59976220-8776-4AD8-8D71-D1C89F623719@daydream.com> The last nanog was in June. The next is in October Cathy Sent from a handheld device. > On Jul 1, 2014, at 7:10 PM, Derek Calanchini wrote: > > Is there a NANOG this month? For some reason I though it was supposed to be around now? > Best regards, > > Derek Calanchini > Owner > Creative Network Solutions > Phone: 916-852-2890 > Fax: 916-852-2899 > > "Adopt the metric system!" > > >> On 7/1/2014 1:33 PM, Matthew Petach wrote: >> >> >> >>> On Mon, Jun 30, 2014 at 4:59 PM, Martin Hannigan wrote: >>> >>> Scott, >>> >>> Asking me to do the work the AC is supposed to do is like asking a nun to certify their virginity. >> >> In the interests of supporting our community, I volunteer to ... >> >> oh, wait. Wrong question. >> >> I mean "I support this proposal". >> >> Matt >> >>> >>> I made my point and I feel zero need to defend what is completely obvious and on the record. >>> >>> As I explained to our "CEO and President", feel free to demonstrate otherwise. >>> >>> Best, >>> >>> Martin >>> >>> >>> >>> On Jun 30, 2014, at 19:38, Scott Leibrand wrote: >>> >>>> Martin, >>>> >>>> I felt the objections raised at previous meetings were addressed, not ignored. Can you clarify how you feel that this policy would make it harder for a recipient to qualify to receive space via transfer? The intent here is to allow organizations to create new discrete networks and qualify for space from them. If you think it will do the opposite, it's worth detailing how and why. >>>> >>>> It's also worth noting that, by documenting the basic requirements for such networks, it also reduces ARIN staff's discretion and provides additional policy certainty. >>>> >>>> Scott >>>> >>>> On Jun 30, 2014, at 3:58 PM, Martin Hannigan wrote: >>>> >>>>> Objection, with the majority of the community from the previous ARIN meeting, recent NANOG PPC and other comments and fora discussion. >>>>> >>>>> But don't let that stop the ARIN AC from moving it forward in its obsession with controlling v4 markets. >>>>> >>>>> Best, >>>>> >>>>> -M< >>>>> >>>>> >>>>> On Jun 30, 2014, at 17:34, CJ Aronson wrote: >>>>> >>>>>> Hi everyone >>>>>> >>>>>> Does anyone have comments on this recommended draft policy? >>>>>> >>>>>> Thanks! >>>>>> ----Cathy >>>>>> >>>>>> >>>>>>> On Tue, Jun 24, 2014 at 2:16 PM, ARIN wrote: >>>>>>> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to >>>>>>> send the following to last call: >>>>>>> >>>>>>> Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks >>>>>>> >>>>>>> Feedback is encouraged during the last call period. All comments should >>>>>>> be provided to the Public Policy Mailing List. This last call will >>>>>>> expire on 8 July 2014. 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-2013-8 >>>>>>> Subsequent Allocations for New Multiple Discrete Networks >>>>>>> >>>>>>> Date: 16 May 2014 >>>>>>> >>>>>>> AC's assessment of conformance with the Principles of Internet Number Resource Policy: >>>>>>> >>>>>>> This proposal enables fair and impartial number resource administration by documenting how to get a new block for a new discrete network. Previous versions of the policy did have this information and over time it has been removed. >>>>>>> >>>>>>> This proposal is technically sound. There is a need for discrete networks and an organization should have a policy that would allow it to create a new discrete network. >>>>>>> >>>>>>> This proposal is supported by the community. There has been some concern about the criterial that will be used and this version has been updated with the current thinking on the criteria. >>>>>>> >>>>>>> Policy Statement: >>>>>>> >>>>>>> IPv4: >>>>>>> Add the following statement to section 4.5.4. >>>>>>> Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5 unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6). >>>>>>> >>>>>>> IPv6: >>>>>>> Add an additional reference to section 6.11.5.b such that it references both the initial allocation and subsequent allocation sections of the IPv6 LIR policy. >>>>>>> "Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization..." >>>>>>> >>>>>>> Comments: >>>>>>> a. Timetable for implementation: immediate >>>>>>> b. This policy is being proposed based upon the Policy Implementation & Experience Report from ARIN 32. >>>>>>> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf >>>>>>> c: Older versions of the MDN policy did contain new network criteria. This criteria appears to have been dropped during subsequent rewrites of the MDN policy. "The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) >>>>>>> _______________________________________________ >>>>>>> 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. >>> >>> _______________________________________________ >>> 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. > > > > > This email is free from viruses and malware because avast! Antivirus protection is active. > > > _______________________________________________ > 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 narten at us.ibm.com Fri Jul 4 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 04 Jul 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201407040453.s644r3WZ016040@rotala.raleigh.ibm.com> Total of 22 messages in the last 7 days. script run at: Fri Jul 4 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.73% | 5 | 15.74% | 65269 | hannigan at gmail.com 18.18% | 4 | 19.71% | 81738 | cja at daydream.com 4.55% | 1 | 31.02% | 128615 | derekc at cnets.net 13.64% | 3 | 12.68% | 52580 | scottleibrand at gmail.com 13.64% | 3 | 4.31% | 17863 | jcurran at arin.net 4.55% | 1 | 5.31% | 22027 | mpetach at netflight.com 4.55% | 1 | 3.88% | 16098 | celestea at usc.edu 4.55% | 1 | 2.26% | 9382 | khatfield at socllc.net 4.55% | 1 | 2.15% | 8917 | info at arin.net 4.55% | 1 | 1.73% | 7180 | narten at us.ibm.com 4.55% | 1 | 1.19% | 4948 | john at egh.com --------+------+--------+----------+------------------------ 100.00% | 22 |100.00% | 414617 | Total From mike.mazarick at virtudatacenter.com Tue Jul 8 16:57:45 2014 From: mike.mazarick at virtudatacenter.com (Mike Mazarick) Date: Tue, 8 Jul 2014 16:57:45 -0400 Subject: [arin-ppml] comment - Draft Policy ARIN-2013-8 Message-ID: <01c001cf9aef$45776eb0$d0664c10$@mazarick@virtudatacenter.com> RE: Recommended Draft Policy ARIN-2013-8 My comments: All of computer science is made up of allocating storage (memory/disk), de-allocating storage, or moving bits around. Like all organizations, the current situation we are all in (exhaustion of IPv4 addresses) is due to an improper de-allocation of IP addresses. The fact that we are in 2014 after a 30 year run talking about what to do means that de-allocation is already good. The current situation is due to desktops/servers/storage units requiring a new IP address (throwing away the old one) while the core routers have the same IPs that were in place when the internet was created. There have been effective solutions put in place by ARIN and others to 'put a thumb in the dike' of this de-allocation issue. There are many possible solutions, but the proposed solution means that ARIN will 'go slow' with allocating the remaining IPv4 addresses stringing out the deployment of IPv4 addresses for as long as possible. It is already economically very difficult for a new entrant to get 'in' and it will be impossible once the new policies are in place. Now, it is not all bad for there not to be any new entrants into a market (it is the heart of standards), and the market gravitates towards three major solutions anyway once something becomes a commodity. The real question is "has the internet become a commodity already, or is there still some juice left in it?". It is impossible to answer this in advance. I do know that when ARIN was formed, the biggest problem was giving everyone internet connectivity, which involved a major expense running wires, buying wireless spectrum, etc and the investors who made it possible deserve to be paid a profit because they were very successful at deploying internet connectivity. 1) It appears that there will be no new ISPs and no one will get into this business. It is difficult already, but if the draft policy by ARIN is put in place, it solidifies and codifies ARIN's ratification of this. Although we all saw the unintended consequences arising when the US Congress made possible CLECs (which were unsuccessful in the market) and new ISPs are very much like CLECs were, it is a very dangerous thing to provide policy that makes sure there will be no new ISPs because there is no economic incentive for one to be created. The opportunity to get ahead by creating a new ISP will soon be removed by ARIN policy. Does ARIN want to enable the entire country to remain a 'banana republic' where the rich are getting richer at the expense of the middle class/small business, or does ARIN wish to be associated with the 'land of opportunity' (not subsidy) by allocating resources to large and small enterprises on an equal basis? 2) There is no need to mess with IPv6 policy. The current situation which we have all been trying to implement for a decade will not be enhanced by this policy change. The change in policy is that IPv4 is getting a lot more restrictive in allocation and IPv6 will be tied to existing IPv4 allocations. It really means that there will not be an opportunity for a new ISP even after the IPv4 addresses are a thing of the past. If it ain't broke, don't fix it. There is ample opportunity for ARIN to create an "intellectual property tax" for payment to ARIN based on existing allocation size and market prices for the IP addresses (separate ones for IPv4 and IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 addresses? 3) If we return to the 'bank of modems' of the dial up modem era, then every modem has to have its own separate dial tone. There may be a way to use one phone number (like IP addresses), but the modem pool still has to have an isolation mechanism per modem. The policy as written will specify that someone getting into the 'dial up modem' business can't deploy but a handful of modems at a time, that all modems must be 80% utilized before any more can be bought, and that the phone number will change for all modems on the modem bank if more modems are deployed. An ISP ensures that a customer is able to put their own phone number on the banks of modems while a large enterprise means that they have to control the phone numbers too. It is a subtle distinction but it at the heart of the question "Does ARIN wish to have a more relaxed policy for large Enterprises than ISPs?". 4) It is important for ARIN to maintain the existing internet policy thru allocation. It is hard to see how the existing policy change will enhance an accurate allocation other than there will be less players to watch after and the expense will be known in advance. Does ARIN want to 'remove the band-aid slowly' which the proposed policy change does, or does ARIN and others involved undergo less pain if the IPv4 band-aid is removed quickly? 5) Doing something now is akin to 'closing the barn door after the horse has run off', similar to anyone that gets broken in to buying a burgler alarm system after they were robbed. In an effort at fairness, because ARIN must serve both large and small internet clients and because of the huge allocations in place in 2012-2013 (.5% of the companies got most of the IP address allocations from ARIN), the attention has been to be fair in administration of ARIN policies. Will the existing policy change enable ARIN to be more or less 'fair' with the remaining IPv4 allocation? Mike Mazarick From matthew at matthew.at Tue Jul 8 19:21:27 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Jul 2014 16:21:27 -0700 Subject: [arin-ppml] comment - Draft Policy ARIN-2013-8 In-Reply-To: <01c001cf9aef$45776eb0$d0664c10$@mazarick@virtudatacenter.com> References: <01c001cf9aef$45776eb0$d0664c10$@mazarick@virtudatacenter.com> Message-ID: <53BC7CF7.4030203@matthew.at> I can't tell... do you support or oppose the policy proposal? Matthew Kaufman On 7/8/2014 1:57 PM, Mike Mazarick wrote: > RE: Recommended Draft Policy ARIN-2013-8 > > My comments: > > All of computer science is made up of allocating storage (memory/disk), > de-allocating storage, or moving bits around. Like all organizations, the > current situation we are all in (exhaustion of IPv4 addresses) is due to an > improper de-allocation of IP addresses. The fact that we are in 2014 after > a 30 year run talking about what to do means that de-allocation is already > good. The current situation is due to desktops/servers/storage units > requiring a new IP address (throwing away the old one) while the core > routers have the same IPs that were in place when the internet was created. > There have been effective solutions put in place by ARIN and others to 'put > a thumb in the dike' of this de-allocation issue. There are many possible > solutions, but the proposed solution means that ARIN will 'go slow' with > allocating the remaining IPv4 addresses stringing out the deployment of IPv4 > addresses for as long as possible. It is already economically very > difficult for a new entrant to get 'in' and it will be impossible once the > new policies are in place. > > Now, it is not all bad for there not to be any new entrants into a market > (it is the heart of standards), and the market gravitates towards three > major solutions anyway once something becomes a commodity. The real > question is "has the internet become a commodity already, or is there still > some juice left in it?". It is impossible to answer this in advance. I > do know that when ARIN was formed, the biggest problem was giving everyone > internet connectivity, which involved a major expense running wires, buying > wireless spectrum, etc and the investors who made it possible deserve to be > paid a profit because they were very successful at deploying internet > connectivity. > > 1) It appears that there will be no new ISPs and no one will get into this > business. It is difficult already, but if the draft policy by ARIN is put > in place, it solidifies and codifies ARIN's ratification of this. Although > we all saw the unintended consequences arising when the US Congress made > possible CLECs (which were unsuccessful in the market) and new ISPs are very > much like CLECs were, it is a very dangerous thing to provide policy that > makes sure there will be no new ISPs because there is no economic incentive > for one to be created. The opportunity to get ahead by creating a new ISP > will soon be removed by ARIN policy. Does ARIN want to enable the entire > country to remain a 'banana republic' where the rich are getting richer at > the expense of the middle class/small business, or does ARIN wish to be > associated with the 'land of opportunity' (not subsidy) by allocating > resources to large and small enterprises on an equal basis? > > 2) There is no need to mess with IPv6 policy. The current situation > which we have all been trying to implement for a decade will not be enhanced > by this policy change. The change in policy is that IPv4 is getting a lot > more restrictive in allocation and IPv6 will be tied to existing IPv4 > allocations. It really means that there will not be an opportunity for a > new ISP even after the IPv4 addresses are a thing of the past. If it ain't > broke, don't fix it. There is ample opportunity for ARIN to create an > "intellectual property tax" for payment to ARIN based on existing allocation > size and market prices for the IP addresses (separate ones for IPv4 and > IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 > addresses? > > 3) If we return to the 'bank of modems' of the dial up modem era, then > every modem has to have its own separate dial tone. There may be a way to > use one phone number (like IP addresses), but the modem pool still has to > have an isolation mechanism per modem. The policy as written will specify > that someone getting into the 'dial up modem' business can't deploy but a > handful of modems at a time, that all modems must be 80% utilized before any > more can be bought, and that the phone number will change for all modems on > the modem bank if more modems are deployed. An ISP ensures that a customer > is able to put their own phone number on the banks of modems while a large > enterprise means that they have to control the phone numbers too. It is a > subtle distinction but it at the heart of the question "Does ARIN wish to > have a more relaxed policy for large Enterprises than ISPs?". > > 4) It is important for ARIN to maintain the existing internet policy thru > allocation. It is hard to see how the existing policy change will enhance > an accurate allocation other than there will be less players to watch after > and the expense will be known in advance. Does ARIN want to 'remove the > band-aid slowly' which the proposed policy change does, or does ARIN and > others involved undergo less pain if the IPv4 band-aid is removed quickly? > > 5) Doing something now is akin to 'closing the barn door after the horse > has run off', similar to anyone that gets broken in to buying a burgler > alarm system after they were robbed. In an effort at fairness, because > ARIN must serve both large and small internet clients and because of the > huge allocations in place in 2012-2013 (.5% of the companies got most of the > IP address allocations from ARIN), the attention has been to be fair in > administration of ARIN policies. Will the existing policy change enable > ARIN to be more or less 'fair' with the remaining IPv4 allocation? > > Mike Mazarick > > > _______________________________________________ > 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 matthew at matthew.at Tue Jul 8 19:38:34 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Jul 2014 16:38:34 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <53A9DC93.20903@arin.net> References: <53A9DC93.20903@arin.net> Message-ID: <53BC80FA.3030102@matthew.at> Support. Additionally I think that the community has made it clear that ARIN should be following their own policies (including this one, if applicable) if/when allocating addresses to themselves. Matthew Kaufman On 6/24/2014 1:16 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 19 June 2014 and decided to > send the following to an extended last call: > > Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy > > The text has been revised. The AC provided the following: > > "ARIN-2014-12 has been modified since the ARIN Advisory Council (AC) > recommended this policy on 15 May 2014, in the following ways; > > 1. The second and third sentences of the policy text were modified to > clarify the original policy intent regarding deviation from the minimum > allocation size, either smaller or larger as discussed on PPML. These > changes are considered editorial in nature and do not change the intent > of the policy. > > 2. A sentence was added to the policy statement reflecting the changes > to the policy text as discussed above." > > 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 15 July 2014. 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-12 > Anti-hijack Policy > > Date: 17 June 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > ARIN-2014-12: Anti-hijack Policy enables fair, impartial, and > technically sound number resource administration by updating the > guidelines for the allocation of experimental resources to ensure all > such allocation are documented in Whois, noting their experimental > status, and provides these allocations may not overlap any other > allocations. Additionally, part of the original policy text has been > clarified through editorial changes. > > Problem Statement: > > ARIN should not give research organizations permission to hijack > prefixes that have already been allocated. Research organizations > announcing lit aggregates may receive sensitive production traffic > belonging to live networks during periods of instability. > > Section 11.7 describes more than allocation size therefore updating > the section heading to something more accurate is appropriate. > > Policy statement: > > Modify the section 11.7 heading to be more accurate. Modify the first > sentence to prohibit overlapping assignments. Add text at the end to > define how research allocations should be designated. > > Modify the second and third sentences to clarify the original policy > intent regarding deviation from the minimum allocation size, smaller > or larger as discussed on PPML. > > 11.7 Resource Allocation Guidelines > > The Numbering Resources requested come from the global Internet > Resource space, do not overlap currently assigned space, and are not > from private or other non-routable Internet Resource space. The > allocation size shall be consistent with the existing ARIN minimum > allocation sizes, unless smaller allocations are intended to be > explicitly part of the experiment. If an organization requires more > resources than stipulated by the minimum allocation size in force at > the time of its request, the request must clearly describe and justify > why a larger allocation is required. > > All research allocations must be registered publicly in whois. Each > research allocation will be designated as a research allocation with a > comment indicating when the allocation will end. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else: > _______________________________________________ > 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 matthew at matthew.at Tue Jul 8 19:39:37 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Jul 2014 16:39:37 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 In-Reply-To: <53A9DCA2.2060907@arin.net> References: <53A9DCA2.2060907@arin.net> Message-ID: <53BC8139.6060803@matthew.at> Support. Making it easier for people to receive the last of the IPv4 pool is a good thing. Matthew Kaufman From matthew at matthew.at Tue Jul 8 19:41:52 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Jul 2014 16:41:52 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations In-Reply-To: <53A9DC75.5060605@arin.net> References: <53A9DC75.5060605@arin.net> Message-ID: <53BC81C0.5050409@matthew.at> Support. Even when DNS software bugs made it critical for ARIN and its predecessors to do their best, this has never been effectively implemented. The good news is that the bugs were fixed as a result, and so this is now a non-issue. Also, generally support removing extraneous language from NRPM. Matthew Kaufman From matthew at matthew.at Tue Jul 8 19:48:54 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Jul 2014 16:48:54 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs TestfromSmall IPv4 Transfers In-Reply-To: References: <537672F4.2060804@arin.net><53A0CD55.3020101@umn.edu><55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu><5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> <807042DE61CB468DA177DD1107BB77B7@MPC> Message-ID: <53BC8366.2020109@matthew.at> I have changed my position on ARIN-2014-14. While I am generally in favor of removing all needs transfers, it seems to me that additional needs-based limitations will actually increase the perceived value of pre-ARIN "legacy" resources and encourage lawsuits that seek to establish ARIN's non-control over said "legacy" resources. I look forward to the entertainment potential of observing the inefficiency and distortion of the post-runout IPv4 market. For the above reason, I oppose ARIN-2014-14, and am readying my popcorn. Matthew Kaufman From mike.mazarick at virtudatacenter.com Tue Jul 8 20:00:04 2014 From: mike.mazarick at virtudatacenter.com (Mike Mazarick) Date: Tue, 8 Jul 2014 20:00:04 -0400 Subject: [arin-ppml] rescind of comments Message-ID: <01e901cf9b08$c11ef970$435cec50$@mazarick@virtudatacenter.com> After a conversation with Owen DeLong, he explained to me that the policy as written only affects Multiple Discrete Networks instead of the NRPM as a whole. I will review this and comment later, but if it only affects Multiple Discrete Networks (a subset of everything ARIN does) and makes it easier to get new IP addresses rather than harder, my earlier comments will be rescinded. Unfortunately, any research needed for this will go past the "last call" period. I had told Owen that I will rescind now and correct it later once there is adequate time to do adequate research. -Mike From rudi.daniel at gmail.com Wed Jul 9 14:34:33 2014 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 9 Jul 2014 14:34:33 -0400 Subject: [arin-ppml] ARIN 2014-13 Message-ID: I Support for /24. RD On Jul 8, 2014 7:42 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. Weekly posting summary for ppml at arin.net (Thomas Narten) > 2. comment - Draft Policy ARIN-2013-8 (Mike Mazarick) > 3. Re: comment - Draft Policy ARIN-2013-8 (Matthew Kaufman) > 4. Re: LAST CALL: Recommended Draft Policy ARIN-2014-12: > Anti-hijack Policy (Matthew Kaufman) > 5. Re: LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce > All Minimum Allocation/Assignment Units to /24 (Matthew Kaufman) > 6. Re: LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove > 7.2 Lame Delegations (Matthew Kaufman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 04 Jul 2014 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: <201407040453.s644r3WZ016040 at rotala.raleigh.ibm.com> > Content-Type: text/plain; charset=us-ascii > > Total of 22 messages in the last 7 days. > > script run at: Fri Jul 4 00:53:03 EDT 2014 > > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 22.73% | 5 | 15.74% | 65269 | hannigan at gmail.com > 18.18% | 4 | 19.71% | 81738 | cja at daydream.com > 4.55% | 1 | 31.02% | 128615 | derekc at cnets.net > 13.64% | 3 | 12.68% | 52580 | scottleibrand at gmail.com > 13.64% | 3 | 4.31% | 17863 | jcurran at arin.net > 4.55% | 1 | 5.31% | 22027 | mpetach at netflight.com > 4.55% | 1 | 3.88% | 16098 | celestea at usc.edu > 4.55% | 1 | 2.26% | 9382 | khatfield at socllc.net > 4.55% | 1 | 2.15% | 8917 | info at arin.net > 4.55% | 1 | 1.73% | 7180 | narten at us.ibm.com > 4.55% | 1 | 1.19% | 4948 | john at egh.com > --------+------+--------+----------+------------------------ > 100.00% | 22 |100.00% | 414617 | Total > > > > ------------------------------ > > Message: 2 > Date: Tue, 8 Jul 2014 16:57:45 -0400 > From: "Mike Mazarick" > To: > Subject: [arin-ppml] comment - Draft Policy ARIN-2013-8 > Message-ID: > <01c001cf9aef$45776eb0$d0664c10$@mazarick at virtudatacenter.com> > Content-Type: text/plain; charset="us-ascii" > > RE: Recommended Draft Policy ARIN-2013-8 > > My comments: > > All of computer science is made up of allocating storage (memory/disk), > de-allocating storage, or moving bits around. Like all organizations, the > current situation we are all in (exhaustion of IPv4 addresses) is due to an > improper de-allocation of IP addresses. The fact that we are in 2014 > after > a 30 year run talking about what to do means that de-allocation is already > good. The current situation is due to desktops/servers/storage units > requiring a new IP address (throwing away the old one) while the core > routers have the same IPs that were in place when the internet was created. > There have been effective solutions put in place by ARIN and others to 'put > a thumb in the dike' of this de-allocation issue. There are many possible > solutions, but the proposed solution means that ARIN will 'go slow' with > allocating the remaining IPv4 addresses stringing out the deployment of > IPv4 > addresses for as long as possible. It is already economically very > difficult for a new entrant to get 'in' and it will be impossible once the > new policies are in place. > > Now, it is not all bad for there not to be any new entrants into a market > (it is the heart of standards), and the market gravitates towards three > major solutions anyway once something becomes a commodity. The real > question is "has the internet become a commodity already, or is there still > some juice left in it?". It is impossible to answer this in advance. I > do know that when ARIN was formed, the biggest problem was giving everyone > internet connectivity, which involved a major expense running wires, buying > wireless spectrum, etc and the investors who made it possible deserve to be > paid a profit because they were very successful at deploying internet > connectivity. > > 1) It appears that there will be no new ISPs and no one will get into > this > business. It is difficult already, but if the draft policy by ARIN is put > in place, it solidifies and codifies ARIN's ratification of this. Although > we all saw the unintended consequences arising when the US Congress made > possible CLECs (which were unsuccessful in the market) and new ISPs are > very > much like CLECs were, it is a very dangerous thing to provide policy that > makes sure there will be no new ISPs because there is no economic incentive > for one to be created. The opportunity to get ahead by creating a new ISP > will soon be removed by ARIN policy. Does ARIN want to enable the entire > country to remain a 'banana republic' where the rich are getting richer at > the expense of the middle class/small business, or does ARIN wish to be > associated with the 'land of opportunity' (not subsidy) by allocating > resources to large and small enterprises on an equal basis? > > 2) There is no need to mess with IPv6 policy. The current situation > which we have all been trying to implement for a decade will not be > enhanced > by this policy change. The change in policy is that IPv4 is getting a lot > more restrictive in allocation and IPv6 will be tied to existing IPv4 > allocations. It really means that there will not be an opportunity for a > new ISP even after the IPv4 addresses are a thing of the past. If it > ain't > broke, don't fix it. There is ample opportunity for ARIN to create an > "intellectual property tax" for payment to ARIN based on existing > allocation > size and market prices for the IP addresses (separate ones for IPv4 and > IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 > addresses? > > 3) If we return to the 'bank of modems' of the dial up modem era, then > every modem has to have its own separate dial tone. There may be a way to > use one phone number (like IP addresses), but the modem pool still has to > have an isolation mechanism per modem. The policy as written will specify > that someone getting into the 'dial up modem' business can't deploy but a > handful of modems at a time, that all modems must be 80% utilized before > any > more can be bought, and that the phone number will change for all modems on > the modem bank if more modems are deployed. An ISP ensures that a > customer > is able to put their own phone number on the banks of modems while a large > enterprise means that they have to control the phone numbers too. It is a > subtle distinction but it at the heart of the question "Does ARIN wish to > have a more relaxed policy for large Enterprises than ISPs?". > > 4) It is important for ARIN to maintain the existing internet policy thru > allocation. It is hard to see how the existing policy change will enhance > an accurate allocation other than there will be less players to watch after > and the expense will be known in advance. Does ARIN want to 'remove the > band-aid slowly' which the proposed policy change does, or does ARIN and > others involved undergo less pain if the IPv4 band-aid is removed quickly? > > 5) Doing something now is akin to 'closing the barn door after the horse > has run off', similar to anyone that gets broken in to buying a burgler > alarm system after they were robbed. In an effort at fairness, because > ARIN must serve both large and small internet clients and because of the > huge allocations in place in 2012-2013 (.5% of the companies got most of > the > IP address allocations from ARIN), the attention has been to be fair in > administration of ARIN policies. Will the existing policy change enable > ARIN to be more or less 'fair' with the remaining IPv4 allocation? > > Mike Mazarick > > > > > ------------------------------ > > Message: 3 > Date: Tue, 08 Jul 2014 16:21:27 -0700 > From: Matthew Kaufman > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] comment - Draft Policy ARIN-2013-8 > Message-ID: <53BC7CF7.4030203 at matthew.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I can't tell... do you support or oppose the policy proposal? > > Matthew Kaufman > > On 7/8/2014 1:57 PM, Mike Mazarick wrote: > > RE: Recommended Draft Policy ARIN-2013-8 > > > > My comments: > > > > All of computer science is made up of allocating storage (memory/disk), > > de-allocating storage, or moving bits around. Like all organizations, > the > > current situation we are all in (exhaustion of IPv4 addresses) is due to > an > > improper de-allocation of IP addresses. The fact that we are in 2014 > after > > a 30 year run talking about what to do means that de-allocation is > already > > good. The current situation is due to desktops/servers/storage units > > requiring a new IP address (throwing away the old one) while the core > > routers have the same IPs that were in place when the internet was > created. > > There have been effective solutions put in place by ARIN and others to > 'put > > a thumb in the dike' of this de-allocation issue. There are many > possible > > solutions, but the proposed solution means that ARIN will 'go slow' with > > allocating the remaining IPv4 addresses stringing out the deployment of > IPv4 > > addresses for as long as possible. It is already economically very > > difficult for a new entrant to get 'in' and it will be impossible once > the > > new policies are in place. > > > > Now, it is not all bad for there not to be any new entrants into a market > > (it is the heart of standards), and the market gravitates towards three > > major solutions anyway once something becomes a commodity. The real > > question is "has the internet become a commodity already, or is there > still > > some juice left in it?". It is impossible to answer this in advance. > I > > do know that when ARIN was formed, the biggest problem was giving > everyone > > internet connectivity, which involved a major expense running wires, > buying > > wireless spectrum, etc and the investors who made it possible deserve to > be > > paid a profit because they were very successful at deploying internet > > connectivity. > > > > 1) It appears that there will be no new ISPs and no one will get into > this > > business. It is difficult already, but if the draft policy by ARIN is > put > > in place, it solidifies and codifies ARIN's ratification of this. > Although > > we all saw the unintended consequences arising when the US Congress made > > possible CLECs (which were unsuccessful in the market) and new ISPs are > very > > much like CLECs were, it is a very dangerous thing to provide policy that > > makes sure there will be no new ISPs because there is no economic > incentive > > for one to be created. The opportunity to get ahead by creating a new > ISP > > will soon be removed by ARIN policy. Does ARIN want to enable the > entire > > country to remain a 'banana republic' where the rich are getting richer > at > > the expense of the middle class/small business, or does ARIN wish to be > > associated with the 'land of opportunity' (not subsidy) by allocating > > resources to large and small enterprises on an equal basis? > > > > 2) There is no need to mess with IPv6 policy. The current situation > > which we have all been trying to implement for a decade will not be > enhanced > > by this policy change. The change in policy is that IPv4 is getting a > lot > > more restrictive in allocation and IPv6 will be tied to existing IPv4 > > allocations. It really means that there will not be an opportunity for > a > > new ISP even after the IPv4 addresses are a thing of the past. If it > ain't > > broke, don't fix it. There is ample opportunity for ARIN to create an > > "intellectual property tax" for payment to ARIN based on existing > allocation > > size and market prices for the IP addresses (separate ones for IPv4 and > > IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 > > addresses? > > > > 3) If we return to the 'bank of modems' of the dial up modem era, then > > every modem has to have its own separate dial tone. There may be a way > to > > use one phone number (like IP addresses), but the modem pool still has to > > have an isolation mechanism per modem. The policy as written will > specify > > that someone getting into the 'dial up modem' business can't deploy but a > > handful of modems at a time, that all modems must be 80% utilized before > any > > more can be bought, and that the phone number will change for all modems > on > > the modem bank if more modems are deployed. An ISP ensures that a > customer > > is able to put their own phone number on the banks of modems while a > large > > enterprise means that they have to control the phone numbers too. It > is a > > subtle distinction but it at the heart of the question "Does ARIN wish to > > have a more relaxed policy for large Enterprises than ISPs?". > > > > 4) It is important for ARIN to maintain the existing internet policy > thru > > allocation. It is hard to see how the existing policy change will > enhance > > an accurate allocation other than there will be less players to watch > after > > and the expense will be known in advance. Does ARIN want to 'remove the > > band-aid slowly' which the proposed policy change does, or does ARIN and > > others involved undergo less pain if the IPv4 band-aid is removed > quickly? > > > > 5) Doing something now is akin to 'closing the barn door after the horse > > has run off', similar to anyone that gets broken in to buying a burgler > > alarm system after they were robbed. In an effort at fairness, because > > ARIN must serve both large and small internet clients and because of the > > huge allocations in place in 2012-2013 (.5% of the companies got most of > the > > IP address allocations from ARIN), the attention has been to be fair in > > administration of ARIN policies. Will the existing policy change enable > > ARIN to be more or less 'fair' with the remaining IPv4 allocation? > > > > Mike Mazarick > > > > > > _______________________________________________ > > 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: 4 > Date: Tue, 08 Jul 2014 16:38:34 -0700 > From: Matthew Kaufman > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy > ARIN-2014-12: Anti-hijack Policy > Message-ID: <53BC80FA.3030102 at matthew.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Support. Additionally I think that the community has made it clear that > ARIN should be following their own policies (including this one, if > applicable) if/when allocating addresses to themselves. > > Matthew Kaufman > > On 6/24/2014 1:16 PM, ARIN wrote: > > The ARIN Advisory Council (AC) met on 19 June 2014 and decided to > > send the following to an extended last call: > > > > Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy > > > > The text has been revised. The AC provided the following: > > > > "ARIN-2014-12 has been modified since the ARIN Advisory Council (AC) > > recommended this policy on 15 May 2014, in the following ways; > > > > 1. The second and third sentences of the policy text were modified to > > clarify the original policy intent regarding deviation from the minimum > > allocation size, either smaller or larger as discussed on PPML. These > > changes are considered editorial in nature and do not change the intent > > of the policy. > > > > 2. A sentence was added to the policy statement reflecting the changes > > to the policy text as discussed above." > > > > 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 15 July 2014. 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-12 > > Anti-hijack Policy > > > > Date: 17 June 2014 > > > > AC's assessment of conformance with the Principles of Internet Number > > Resource Policy: > > > > ARIN-2014-12: Anti-hijack Policy enables fair, impartial, and > > technically sound number resource administration by updating the > > guidelines for the allocation of experimental resources to ensure all > > such allocation are documented in Whois, noting their experimental > > status, and provides these allocations may not overlap any other > > allocations. Additionally, part of the original policy text has been > > clarified through editorial changes. > > > > Problem Statement: > > > > ARIN should not give research organizations permission to hijack > > prefixes that have already been allocated. Research organizations > > announcing lit aggregates may receive sensitive production traffic > > belonging to live networks during periods of instability. > > > > Section 11.7 describes more than allocation size therefore updating > > the section heading to something more accurate is appropriate. > > > > Policy statement: > > > > Modify the section 11.7 heading to be more accurate. Modify the first > > sentence to prohibit overlapping assignments. Add text at the end to > > define how research allocations should be designated. > > > > Modify the second and third sentences to clarify the original policy > > intent regarding deviation from the minimum allocation size, smaller > > or larger as discussed on PPML. > > > > 11.7 Resource Allocation Guidelines > > > > The Numbering Resources requested come from the global Internet > > Resource space, do not overlap currently assigned space, and are not > > from private or other non-routable Internet Resource space. The > > allocation size shall be consistent with the existing ARIN minimum > > allocation sizes, unless smaller allocations are intended to be > > explicitly part of the experiment. If an organization requires more > > resources than stipulated by the minimum allocation size in force at > > the time of its request, the request must clearly describe and justify > > why a larger allocation is required. > > > > All research allocations must be registered publicly in whois. Each > > research allocation will be designated as a research allocation with a > > comment indicating when the allocation will end. > > > > Comments: > > > > a. Timetable for implementation: Immediate > > > > b. Anything else: > > _______________________________________________ > > 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: Tue, 08 Jul 2014 16:39:37 -0700 > From: Matthew Kaufman > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy > ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 > Message-ID: <53BC8139.6060803 at matthew.at> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Support. Making it easier for people to receive the last of the IPv4 > pool is a good thing. > > Matthew Kaufman > > > ------------------------------ > > Message: 6 > Date: Tue, 08 Jul 2014 16:41:52 -0700 > From: Matthew Kaufman > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy > ARIN-2014-5: Remove 7.2 Lame Delegations > Message-ID: <53BC81C0.5050409 at matthew.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Support. Even when DNS software bugs made it critical for ARIN and its > predecessors to do their best, this has never been effectively > implemented. The good news is that the bugs were fixed as a result, and > so this is now a non-issue. Also, generally support removing extraneous > language from NRPM. > > Matthew Kaufman > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 109, Issue 4 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Thu Jul 10 14:53:51 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 10 Jul 2014 18:53:51 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: References: Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.com> I think it makes sense to rethink 2014-13. Changing all Minimum Allocations to a /24 will have the effect of making it harder for Organizations to get blocks that are larger than a /24. I think a better alternative would be to set a Minimum Range. That would allow the smallest Organizations to get a /24 but a slightly larger Organization can still get a /20 or a /22 as they are defined in various current policies. This would mean that if the current Minimum in a particular policy is a /20 then it would change to be a Minimum Range of /20 down to a /24. If the particular policy is currently at /22 it would change to be a Minimum Range of /22 down to a /24. If the current policy is at /24 it would not change. I?m all for fairness at the low end of the allocation range - but don?t want to have a policy that is intended to make it easier to get an allocation have the reverse effect of making it harder to get something larger than a /24. My two cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel Sent: Wednesday, July 9, 2014 2:35 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 I Support for /24. RD On Jul 8, 2014 7:42 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. Weekly posting summary for ppml at arin.net (Thomas Narten) 2. comment - Draft Policy ARIN-2013-8 (Mike Mazarick) 3. Re: comment - Draft Policy ARIN-2013-8 (Matthew Kaufman) 4. Re: LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy (Matthew Kaufman) 5. Re: LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 (Matthew Kaufman) 6. Re: LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations (Matthew Kaufman) ---------------------------------------------------------------------- Message: 1 Date: Fri, 04 Jul 2014 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: <201407040453.s644r3WZ016040 at rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Total of 22 messages in the last 7 days. script run at: Fri Jul 4 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.73% | 5 | 15.74% | 65269 | hannigan at gmail.com 18.18% | 4 | 19.71% | 81738 | cja at daydream.com 4.55% | 1 | 31.02% | 128615 | derekc at cnets.net 13.64% | 3 | 12.68% | 52580 | scottleibrand at gmail.com 13.64% | 3 | 4.31% | 17863 | jcurran at arin.net 4.55% | 1 | 5.31% | 22027 | mpetach at netflight.com 4.55% | 1 | 3.88% | 16098 | celestea at usc.edu 4.55% | 1 | 2.26% | 9382 | khatfield at socllc.net 4.55% | 1 | 2.15% | 8917 | info at arin.net 4.55% | 1 | 1.73% | 7180 | narten at us.ibm.com 4.55% | 1 | 1.19% | 4948 | john at egh.com --------+------+--------+----------+------------------------ 100.00% | 22 |100.00% | 414617 | Total ------------------------------ Message: 2 Date: Tue, 8 Jul 2014 16:57:45 -0400 From: "Mike Mazarick" > To: > Subject: [arin-ppml] comment - Draft Policy ARIN-2013-8 Message-ID: <01c001cf9aef$45776eb0$d0664c10$@mazarick at virtudatacenter.com> Content-Type: text/plain; charset="us-ascii" RE: Recommended Draft Policy ARIN-2013-8 My comments: All of computer science is made up of allocating storage (memory/disk), de-allocating storage, or moving bits around. Like all organizations, the current situation we are all in (exhaustion of IPv4 addresses) is due to an improper de-allocation of IP addresses. The fact that we are in 2014 after a 30 year run talking about what to do means that de-allocation is already good. The current situation is due to desktops/servers/storage units requiring a new IP address (throwing away the old one) while the core routers have the same IPs that were in place when the internet was created. There have been effective solutions put in place by ARIN and others to 'put a thumb in the dike' of this de-allocation issue. There are many possible solutions, but the proposed solution means that ARIN will 'go slow' with allocating the remaining IPv4 addresses stringing out the deployment of IPv4 addresses for as long as possible. It is already economically very difficult for a new entrant to get 'in' and it will be impossible once the new policies are in place. Now, it is not all bad for there not to be any new entrants into a market (it is the heart of standards), and the market gravitates towards three major solutions anyway once something becomes a commodity. The real question is "has the internet become a commodity already, or is there still some juice left in it?". It is impossible to answer this in advance. I do know that when ARIN was formed, the biggest problem was giving everyone internet connectivity, which involved a major expense running wires, buying wireless spectrum, etc and the investors who made it possible deserve to be paid a profit because they were very successful at deploying internet connectivity. 1) It appears that there will be no new ISPs and no one will get into this business. It is difficult already, but if the draft policy by ARIN is put in place, it solidifies and codifies ARIN's ratification of this. Although we all saw the unintended consequences arising when the US Congress made possible CLECs (which were unsuccessful in the market) and new ISPs are very much like CLECs were, it is a very dangerous thing to provide policy that makes sure there will be no new ISPs because there is no economic incentive for one to be created. The opportunity to get ahead by creating a new ISP will soon be removed by ARIN policy. Does ARIN want to enable the entire country to remain a 'banana republic' where the rich are getting richer at the expense of the middle class/small business, or does ARIN wish to be associated with the 'land of opportunity' (not subsidy) by allocating resources to large and small enterprises on an equal basis? 2) There is no need to mess with IPv6 policy. The current situation which we have all been trying to implement for a decade will not be enhanced by this policy change. The change in policy is that IPv4 is getting a lot more restrictive in allocation and IPv6 will be tied to existing IPv4 allocations. It really means that there will not be an opportunity for a new ISP even after the IPv4 addresses are a thing of the past. If it ain't broke, don't fix it. There is ample opportunity for ARIN to create an "intellectual property tax" for payment to ARIN based on existing allocation size and market prices for the IP addresses (separate ones for IPv4 and IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 addresses? 3) If we return to the 'bank of modems' of the dial up modem era, then every modem has to have its own separate dial tone. There may be a way to use one phone number (like IP addresses), but the modem pool still has to have an isolation mechanism per modem. The policy as written will specify that someone getting into the 'dial up modem' business can't deploy but a handful of modems at a time, that all modems must be 80% utilized before any more can be bought, and that the phone number will change for all modems on the modem bank if more modems are deployed. An ISP ensures that a customer is able to put their own phone number on the banks of modems while a large enterprise means that they have to control the phone numbers too. It is a subtle distinction but it at the heart of the question "Does ARIN wish to have a more relaxed policy for large Enterprises than ISPs?". 4) It is important for ARIN to maintain the existing internet policy thru allocation. It is hard to see how the existing policy change will enhance an accurate allocation other than there will be less players to watch after and the expense will be known in advance. Does ARIN want to 'remove the band-aid slowly' which the proposed policy change does, or does ARIN and others involved undergo less pain if the IPv4 band-aid is removed quickly? 5) Doing something now is akin to 'closing the barn door after the horse has run off', similar to anyone that gets broken in to buying a burgler alarm system after they were robbed. In an effort at fairness, because ARIN must serve both large and small internet clients and because of the huge allocations in place in 2012-2013 (.5% of the companies got most of the IP address allocations from ARIN), the attention has been to be fair in administration of ARIN policies. Will the existing policy change enable ARIN to be more or less 'fair' with the remaining IPv4 allocation? Mike Mazarick ------------------------------ Message: 3 Date: Tue, 08 Jul 2014 16:21:27 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] comment - Draft Policy ARIN-2013-8 Message-ID: <53BC7CF7.4030203 at matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I can't tell... do you support or oppose the policy proposal? Matthew Kaufman On 7/8/2014 1:57 PM, Mike Mazarick wrote: > RE: Recommended Draft Policy ARIN-2013-8 > > My comments: > > All of computer science is made up of allocating storage (memory/disk), > de-allocating storage, or moving bits around. Like all organizations, the > current situation we are all in (exhaustion of IPv4 addresses) is due to an > improper de-allocation of IP addresses. The fact that we are in 2014 after > a 30 year run talking about what to do means that de-allocation is already > good. The current situation is due to desktops/servers/storage units > requiring a new IP address (throwing away the old one) while the core > routers have the same IPs that were in place when the internet was created. > There have been effective solutions put in place by ARIN and others to 'put > a thumb in the dike' of this de-allocation issue. There are many possible > solutions, but the proposed solution means that ARIN will 'go slow' with > allocating the remaining IPv4 addresses stringing out the deployment of IPv4 > addresses for as long as possible. It is already economically very > difficult for a new entrant to get 'in' and it will be impossible once the > new policies are in place. > > Now, it is not all bad for there not to be any new entrants into a market > (it is the heart of standards), and the market gravitates towards three > major solutions anyway once something becomes a commodity. The real > question is "has the internet become a commodity already, or is there still > some juice left in it?". It is impossible to answer this in advance. I > do know that when ARIN was formed, the biggest problem was giving everyone > internet connectivity, which involved a major expense running wires, buying > wireless spectrum, etc and the investors who made it possible deserve to be > paid a profit because they were very successful at deploying internet > connectivity. > > 1) It appears that there will be no new ISPs and no one will get into this > business. It is difficult already, but if the draft policy by ARIN is put > in place, it solidifies and codifies ARIN's ratification of this. Although > we all saw the unintended consequences arising when the US Congress made > possible CLECs (which were unsuccessful in the market) and new ISPs are very > much like CLECs were, it is a very dangerous thing to provide policy that > makes sure there will be no new ISPs because there is no economic incentive > for one to be created. The opportunity to get ahead by creating a new ISP > will soon be removed by ARIN policy. Does ARIN want to enable the entire > country to remain a 'banana republic' where the rich are getting richer at > the expense of the middle class/small business, or does ARIN wish to be > associated with the 'land of opportunity' (not subsidy) by allocating > resources to large and small enterprises on an equal basis? > > 2) There is no need to mess with IPv6 policy. The current situation > which we have all been trying to implement for a decade will not be enhanced > by this policy change. The change in policy is that IPv4 is getting a lot > more restrictive in allocation and IPv6 will be tied to existing IPv4 > allocations. It really means that there will not be an opportunity for a > new ISP even after the IPv4 addresses are a thing of the past. If it ain't > broke, don't fix it. There is ample opportunity for ARIN to create an > "intellectual property tax" for payment to ARIN based on existing allocation > size and market prices for the IP addresses (separate ones for IPv4 and > IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 > addresses? > > 3) If we return to the 'bank of modems' of the dial up modem era, then > every modem has to have its own separate dial tone. There may be a way to > use one phone number (like IP addresses), but the modem pool still has to > have an isolation mechanism per modem. The policy as written will specify > that someone getting into the 'dial up modem' business can't deploy but a > handful of modems at a time, that all modems must be 80% utilized before any > more can be bought, and that the phone number will change for all modems on > the modem bank if more modems are deployed. An ISP ensures that a customer > is able to put their own phone number on the banks of modems while a large > enterprise means that they have to control the phone numbers too. It is a > subtle distinction but it at the heart of the question "Does ARIN wish to > have a more relaxed policy for large Enterprises than ISPs?". > > 4) It is important for ARIN to maintain the existing internet policy thru > allocation. It is hard to see how the existing policy change will enhance > an accurate allocation other than there will be less players to watch after > and the expense will be known in advance. Does ARIN want to 'remove the > band-aid slowly' which the proposed policy change does, or does ARIN and > others involved undergo less pain if the IPv4 band-aid is removed quickly? > > 5) Doing something now is akin to 'closing the barn door after the horse > has run off', similar to anyone that gets broken in to buying a burgler > alarm system after they were robbed. In an effort at fairness, because > ARIN must serve both large and small internet clients and because of the > huge allocations in place in 2012-2013 (.5% of the companies got most of the > IP address allocations from ARIN), the attention has been to be fair in > administration of ARIN policies. Will the existing policy change enable > ARIN to be more or less 'fair' with the remaining IPv4 allocation? > > Mike Mazarick > > > _______________________________________________ > 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: 4 Date: Tue, 08 Jul 2014 16:38:34 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy Message-ID: <53BC80FA.3030102 at matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Support. Additionally I think that the community has made it clear that ARIN should be following their own policies (including this one, if applicable) if/when allocating addresses to themselves. Matthew Kaufman On 6/24/2014 1:16 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 19 June 2014 and decided to > send the following to an extended last call: > > Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy > > The text has been revised. The AC provided the following: > > "ARIN-2014-12 has been modified since the ARIN Advisory Council (AC) > recommended this policy on 15 May 2014, in the following ways; > > 1. The second and third sentences of the policy text were modified to > clarify the original policy intent regarding deviation from the minimum > allocation size, either smaller or larger as discussed on PPML. These > changes are considered editorial in nature and do not change the intent > of the policy. > > 2. A sentence was added to the policy statement reflecting the changes > to the policy text as discussed above." > > 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 15 July 2014. 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-12 > Anti-hijack Policy > > Date: 17 June 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > ARIN-2014-12: Anti-hijack Policy enables fair, impartial, and > technically sound number resource administration by updating the > guidelines for the allocation of experimental resources to ensure all > such allocation are documented in Whois, noting their experimental > status, and provides these allocations may not overlap any other > allocations. Additionally, part of the original policy text has been > clarified through editorial changes. > > Problem Statement: > > ARIN should not give research organizations permission to hijack > prefixes that have already been allocated. Research organizations > announcing lit aggregates may receive sensitive production traffic > belonging to live networks during periods of instability. > > Section 11.7 describes more than allocation size therefore updating > the section heading to something more accurate is appropriate. > > Policy statement: > > Modify the section 11.7 heading to be more accurate. Modify the first > sentence to prohibit overlapping assignments. Add text at the end to > define how research allocations should be designated. > > Modify the second and third sentences to clarify the original policy > intent regarding deviation from the minimum allocation size, smaller > or larger as discussed on PPML. > > 11.7 Resource Allocation Guidelines > > The Numbering Resources requested come from the global Internet > Resource space, do not overlap currently assigned space, and are not > from private or other non-routable Internet Resource space. The > allocation size shall be consistent with the existing ARIN minimum > allocation sizes, unless smaller allocations are intended to be > explicitly part of the experiment. If an organization requires more > resources than stipulated by the minimum allocation size in force at > the time of its request, the request must clearly describe and justify > why a larger allocation is required. > > All research allocations must be registered publicly in whois. Each > research allocation will be designated as a research allocation with a > comment indicating when the allocation will end. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else: > _______________________________________________ > 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: Tue, 08 Jul 2014 16:39:37 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 Message-ID: <53BC8139.6060803 at matthew.at> Content-Type: text/plain; charset=windows-1252; format=flowed Support. Making it easier for people to receive the last of the IPv4 pool is a good thing. Matthew Kaufman ------------------------------ Message: 6 Date: Tue, 08 Jul 2014 16:41:52 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations Message-ID: <53BC81C0.5050409 at matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Support. Even when DNS software bugs made it critical for ARIN and its predecessors to do their best, this has never been effectively implemented. The good news is that the bugs were fixed as a result, and so this is now a non-issue. Also, generally support removing extraneous language from NRPM. Matthew Kaufman ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 109, Issue 4 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From farmer at umn.edu Thu Jul 10 18:24:38 2014 From: farmer at umn.edu (David Farmer) Date: Thu, 10 Jul 2014 17:24:38 -0500 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <53A9F0E2.7070103@umn.edu> References: <53A9DC93.20903@arin.net> <53A9F0E2.7070103@umn.edu> Message-ID: <53BF12A6.2080204@umn.edu> I want to remind everyone that Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy is in Extended Last Call through July 15th, 2014. Changes were made to the text after the ARIN Advisory Council advanced it to Recommended Draft policy and after it was presented at the PPC at NANOG 61, based on community feedback on PPML. It is particularly important that anyone who objects to these changes speak up now, before the end of the Extended Last Call period. Up to this point, based on the support expressed and the lack of any objection, I intend to recommend to the full AC we advance this policy to the Board for adoption. Therefore, if there are any objections out there, please raise them ASAP and before July 15th at the latest. Again, the changes made are detailed below. Thanks, and I wish you a beautiful summer weekend. On 6/24/14, 16:42 , David Farmer wrote: > To help additionally highlight the changes to the Policy Text since > the 15 May 2014 version that the AC recommended; I'm including this > HTMLized red-lined version of the Last Call Policy Text below. Only > the changes since the 15 May 2014 version that the AC recommended are > being highlighted. As stated these changes are considered editorial > in nature and are not intended to change the intent or meaning of the > policy, only clarify the original intent. The red text has been added > and red text with a strike-through has been deleted. > > --- > 11.7 Resource Allocation Guidelines > > The Numbering Resources requested come from the global Internet > Resource space, do not overlap currently assigned space, and are not > from private or other non-routable Internet Resource space. The > allocation size should shall be consistent with the existing ARIN > minimum allocation sizes, unless smaller allocations are intended to > be explicitly part of the experiment. If an organization requires more > resources than stipulated by the minimum allocation sizes in force at > the time of their its request, their experimental documentation > shouldhave the request must clearly described and justified justify > why this a larger allocation is required. > > All research allocations must be registered publicly in whois. Each > research allocation will be designated as a research allocation with a > comment indicating when the allocation will end. > --- > > If you are not using a HTML compatible email client then please refer > to the clean text included in the original Last Call email, it will be > difficult to interpret the above text without a HTML compatible email > client. > > Thanks. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Jul 11 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 11 Jul 2014 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201407110453.s6B4r2Ls027527@rotala.raleigh.ibm.com> Total of 11 messages in the last 7 days. script run at: Fri Jul 11 00:53:02 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 45.45% | 5 | 16.15% | 34226 | matthew at matthew.at 9.09% | 1 | 40.94% | 86754 | sryerse at eclipse-networks.com 9.09% | 1 | 25.83% | 54742 | rudi.daniel at gmail.com 18.18% | 2 | 6.99% | 14819 | mike.mazarick at virtudatacenter.com 9.09% | 1 | 6.77% | 14348 | farmer at umn.edu 9.09% | 1 | 3.31% | 7010 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 11 |100.00% | 211899 | Total From kevinb at thewire.ca Sat Jul 12 10:02:43 2014 From: kevinb at thewire.ca (Kevin Blumberg) Date: Sat, 12 Jul 2014 14:02:43 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.com> Message-ID: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> Steven, I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. The minimum on a single homed at /20 in the current text still required needs justification and prevented ISP?s from getting allocations when they did not qualify for the /20. Does that answer your concerns? Thanks, Kevin Blumberg From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Thursday, July 10, 2014 2:54 PM To: Rudolph Daniel; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 I think it makes sense to rethink 2014-13. Changing all Minimum Allocations to a /24 will have the effect of making it harder for Organizations to get blocks that are larger than a /24. I think a better alternative would be to set a Minimum Range. That would allow the smallest Organizations to get a /24 but a slightly larger Organization can still get a /20 or a /22 as they are defined in various current policies. This would mean that if the current Minimum in a particular policy is a /20 then it would change to be a Minimum Range of /20 down to a /24. If the particular policy is currently at /22 it would change to be a Minimum Range of /22 down to a /24. If the current policy is at /24 it would not change. I?m all for fairness at the low end of the allocation range - but don?t want to have a policy that is intended to make it easier to get an allocation have the reverse effect of making it harder to get something larger than a /24. My two cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel Sent: Wednesday, July 9, 2014 2:35 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 I Support for /24. RD On Jul 8, 2014 7:42 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. Weekly posting summary for ppml at arin.net (Thomas Narten) 2. comment - Draft Policy ARIN-2013-8 (Mike Mazarick) 3. Re: comment - Draft Policy ARIN-2013-8 (Matthew Kaufman) 4. Re: LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy (Matthew Kaufman) 5. Re: LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 (Matthew Kaufman) 6. Re: LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations (Matthew Kaufman) ---------------------------------------------------------------------- Message: 1 Date: Fri, 04 Jul 2014 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: <201407040453.s644r3WZ016040 at rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Total of 22 messages in the last 7 days. script run at: Fri Jul 4 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.73% | 5 | 15.74% | 65269 | hannigan at gmail.com 18.18% | 4 | 19.71% | 81738 | cja at daydream.com 4.55% | 1 | 31.02% | 128615 | derekc at cnets.net 13.64% | 3 | 12.68% | 52580 | scottleibrand at gmail.com 13.64% | 3 | 4.31% | 17863 | jcurran at arin.net 4.55% | 1 | 5.31% | 22027 | mpetach at netflight.com 4.55% | 1 | 3.88% | 16098 | celestea at usc.edu 4.55% | 1 | 2.26% | 9382 | khatfield at socllc.net 4.55% | 1 | 2.15% | 8917 | info at arin.net 4.55% | 1 | 1.73% | 7180 | narten at us.ibm.com 4.55% | 1 | 1.19% | 4948 | john at egh.com --------+------+--------+----------+------------------------ 100.00% | 22 |100.00% | 414617 | Total ------------------------------ Message: 2 Date: Tue, 8 Jul 2014 16:57:45 -0400 From: "Mike Mazarick" > To: > Subject: [arin-ppml] comment - Draft Policy ARIN-2013-8 Message-ID: <01c001cf9aef$45776eb0$d0664c10$@mazarick at virtudatacenter.com> Content-Type: text/plain; charset="us-ascii" RE: Recommended Draft Policy ARIN-2013-8 My comments: All of computer science is made up of allocating storage (memory/disk), de-allocating storage, or moving bits around. Like all organizations, the current situation we are all in (exhaustion of IPv4 addresses) is due to an improper de-allocation of IP addresses. The fact that we are in 2014 after a 30 year run talking about what to do means that de-allocation is already good. The current situation is due to desktops/servers/storage units requiring a new IP address (throwing away the old one) while the core routers have the same IPs that were in place when the internet was created. There have been effective solutions put in place by ARIN and others to 'put a thumb in the dike' of this de-allocation issue. There are many possible solutions, but the proposed solution means that ARIN will 'go slow' with allocating the remaining IPv4 addresses stringing out the deployment of IPv4 addresses for as long as possible. It is already economically very difficult for a new entrant to get 'in' and it will be impossible once the new policies are in place. Now, it is not all bad for there not to be any new entrants into a market (it is the heart of standards), and the market gravitates towards three major solutions anyway once something becomes a commodity. The real question is "has the internet become a commodity already, or is there still some juice left in it?". It is impossible to answer this in advance. I do know that when ARIN was formed, the biggest problem was giving everyone internet connectivity, which involved a major expense running wires, buying wireless spectrum, etc and the investors who made it possible deserve to be paid a profit because they were very successful at deploying internet connectivity. 1) It appears that there will be no new ISPs and no one will get into this business. It is difficult already, but if the draft policy by ARIN is put in place, it solidifies and codifies ARIN's ratification of this. Although we all saw the unintended consequences arising when the US Congress made possible CLECs (which were unsuccessful in the market) and new ISPs are very much like CLECs were, it is a very dangerous thing to provide policy that makes sure there will be no new ISPs because there is no economic incentive for one to be created. The opportunity to get ahead by creating a new ISP will soon be removed by ARIN policy. Does ARIN want to enable the entire country to remain a 'banana republic' where the rich are getting richer at the expense of the middle class/small business, or does ARIN wish to be associated with the 'land of opportunity' (not subsidy) by allocating resources to large and small enterprises on an equal basis? 2) There is no need to mess with IPv6 policy. The current situation which we have all been trying to implement for a decade will not be enhanced by this policy change. The change in policy is that IPv4 is getting a lot more restrictive in allocation and IPv6 will be tied to existing IPv4 allocations. It really means that there will not be an opportunity for a new ISP even after the IPv4 addresses are a thing of the past. If it ain't broke, don't fix it. There is ample opportunity for ARIN to create an "intellectual property tax" for payment to ARIN based on existing allocation size and market prices for the IP addresses (separate ones for IPv4 and IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 addresses? 3) If we return to the 'bank of modems' of the dial up modem era, then every modem has to have its own separate dial tone. There may be a way to use one phone number (like IP addresses), but the modem pool still has to have an isolation mechanism per modem. The policy as written will specify that someone getting into the 'dial up modem' business can't deploy but a handful of modems at a time, that all modems must be 80% utilized before any more can be bought, and that the phone number will change for all modems on the modem bank if more modems are deployed. An ISP ensures that a customer is able to put their own phone number on the banks of modems while a large enterprise means that they have to control the phone numbers too. It is a subtle distinction but it at the heart of the question "Does ARIN wish to have a more relaxed policy for large Enterprises than ISPs?". 4) It is important for ARIN to maintain the existing internet policy thru allocation. It is hard to see how the existing policy change will enhance an accurate allocation other than there will be less players to watch after and the expense will be known in advance. Does ARIN want to 'remove the band-aid slowly' which the proposed policy change does, or does ARIN and others involved undergo less pain if the IPv4 band-aid is removed quickly? 5) Doing something now is akin to 'closing the barn door after the horse has run off', similar to anyone that gets broken in to buying a burgler alarm system after they were robbed. In an effort at fairness, because ARIN must serve both large and small internet clients and because of the huge allocations in place in 2012-2013 (.5% of the companies got most of the IP address allocations from ARIN), the attention has been to be fair in administration of ARIN policies. Will the existing policy change enable ARIN to be more or less 'fair' with the remaining IPv4 allocation? Mike Mazarick ------------------------------ Message: 3 Date: Tue, 08 Jul 2014 16:21:27 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] comment - Draft Policy ARIN-2013-8 Message-ID: <53BC7CF7.4030203 at matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I can't tell... do you support or oppose the policy proposal? Matthew Kaufman On 7/8/2014 1:57 PM, Mike Mazarick wrote: > RE: Recommended Draft Policy ARIN-2013-8 > > My comments: > > All of computer science is made up of allocating storage (memory/disk), > de-allocating storage, or moving bits around. Like all organizations, the > current situation we are all in (exhaustion of IPv4 addresses) is due to an > improper de-allocation of IP addresses. The fact that we are in 2014 after > a 30 year run talking about what to do means that de-allocation is already > good. The current situation is due to desktops/servers/storage units > requiring a new IP address (throwing away the old one) while the core > routers have the same IPs that were in place when the internet was created. > There have been effective solutions put in place by ARIN and others to 'put > a thumb in the dike' of this de-allocation issue. There are many possible > solutions, but the proposed solution means that ARIN will 'go slow' with > allocating the remaining IPv4 addresses stringing out the deployment of IPv4 > addresses for as long as possible. It is already economically very > difficult for a new entrant to get 'in' and it will be impossible once the > new policies are in place. > > Now, it is not all bad for there not to be any new entrants into a market > (it is the heart of standards), and the market gravitates towards three > major solutions anyway once something becomes a commodity. The real > question is "has the internet become a commodity already, or is there still > some juice left in it?". It is impossible to answer this in advance. I > do know that when ARIN was formed, the biggest problem was giving everyone > internet connectivity, which involved a major expense running wires, buying > wireless spectrum, etc and the investors who made it possible deserve to be > paid a profit because they were very successful at deploying internet > connectivity. > > 1) It appears that there will be no new ISPs and no one will get into this > business. It is difficult already, but if the draft policy by ARIN is put > in place, it solidifies and codifies ARIN's ratification of this. Although > we all saw the unintended consequences arising when the US Congress made > possible CLECs (which were unsuccessful in the market) and new ISPs are very > much like CLECs were, it is a very dangerous thing to provide policy that > makes sure there will be no new ISPs because there is no economic incentive > for one to be created. The opportunity to get ahead by creating a new ISP > will soon be removed by ARIN policy. Does ARIN want to enable the entire > country to remain a 'banana republic' where the rich are getting richer at > the expense of the middle class/small business, or does ARIN wish to be > associated with the 'land of opportunity' (not subsidy) by allocating > resources to large and small enterprises on an equal basis? > > 2) There is no need to mess with IPv6 policy. The current situation > which we have all been trying to implement for a decade will not be enhanced > by this policy change. The change in policy is that IPv4 is getting a lot > more restrictive in allocation and IPv6 will be tied to existing IPv4 > allocations. It really means that there will not be an opportunity for a > new ISP even after the IPv4 addresses are a thing of the past. If it ain't > broke, don't fix it. There is ample opportunity for ARIN to create an > "intellectual property tax" for payment to ARIN based on existing allocation > size and market prices for the IP addresses (separate ones for IPv4 and > IPv6). Does ARIN want to make sure only incumbents are able to get IPv6 > addresses? > > 3) If we return to the 'bank of modems' of the dial up modem era, then > every modem has to have its own separate dial tone. There may be a way to > use one phone number (like IP addresses), but the modem pool still has to > have an isolation mechanism per modem. The policy as written will specify > that someone getting into the 'dial up modem' business can't deploy but a > handful of modems at a time, that all modems must be 80% utilized before any > more can be bought, and that the phone number will change for all modems on > the modem bank if more modems are deployed. An ISP ensures that a customer > is able to put their own phone number on the banks of modems while a large > enterprise means that they have to control the phone numbers too. It is a > subtle distinction but it at the heart of the question "Does ARIN wish to > have a more relaxed policy for large Enterprises than ISPs?". > > 4) It is important for ARIN to maintain the existing internet policy thru > allocation. It is hard to see how the existing policy change will enhance > an accurate allocation other than there will be less players to watch after > and the expense will be known in advance. Does ARIN want to 'remove the > band-aid slowly' which the proposed policy change does, or does ARIN and > others involved undergo less pain if the IPv4 band-aid is removed quickly? > > 5) Doing something now is akin to 'closing the barn door after the horse > has run off', similar to anyone that gets broken in to buying a burgler > alarm system after they were robbed. In an effort at fairness, because > ARIN must serve both large and small internet clients and because of the > huge allocations in place in 2012-2013 (.5% of the companies got most of the > IP address allocations from ARIN), the attention has been to be fair in > administration of ARIN policies. Will the existing policy change enable > ARIN to be more or less 'fair' with the remaining IPv4 allocation? > > Mike Mazarick > > > _______________________________________________ > 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: 4 Date: Tue, 08 Jul 2014 16:38:34 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy Message-ID: <53BC80FA.3030102 at matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Support. Additionally I think that the community has made it clear that ARIN should be following their own policies (including this one, if applicable) if/when allocating addresses to themselves. Matthew Kaufman On 6/24/2014 1:16 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 19 June 2014 and decided to > send the following to an extended last call: > > Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy > > The text has been revised. The AC provided the following: > > "ARIN-2014-12 has been modified since the ARIN Advisory Council (AC) > recommended this policy on 15 May 2014, in the following ways; > > 1. The second and third sentences of the policy text were modified to > clarify the original policy intent regarding deviation from the minimum > allocation size, either smaller or larger as discussed on PPML. These > changes are considered editorial in nature and do not change the intent > of the policy. > > 2. A sentence was added to the policy statement reflecting the changes > to the policy text as discussed above." > > 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 15 July 2014. 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-12 > Anti-hijack Policy > > Date: 17 June 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > ARIN-2014-12: Anti-hijack Policy enables fair, impartial, and > technically sound number resource administration by updating the > guidelines for the allocation of experimental resources to ensure all > such allocation are documented in Whois, noting their experimental > status, and provides these allocations may not overlap any other > allocations. Additionally, part of the original policy text has been > clarified through editorial changes. > > Problem Statement: > > ARIN should not give research organizations permission to hijack > prefixes that have already been allocated. Research organizations > announcing lit aggregates may receive sensitive production traffic > belonging to live networks during periods of instability. > > Section 11.7 describes more than allocation size therefore updating > the section heading to something more accurate is appropriate. > > Policy statement: > > Modify the section 11.7 heading to be more accurate. Modify the first > sentence to prohibit overlapping assignments. Add text at the end to > define how research allocations should be designated. > > Modify the second and third sentences to clarify the original policy > intent regarding deviation from the minimum allocation size, smaller > or larger as discussed on PPML. > > 11.7 Resource Allocation Guidelines > > The Numbering Resources requested come from the global Internet > Resource space, do not overlap currently assigned space, and are not > from private or other non-routable Internet Resource space. The > allocation size shall be consistent with the existing ARIN minimum > allocation sizes, unless smaller allocations are intended to be > explicitly part of the experiment. If an organization requires more > resources than stipulated by the minimum allocation size in force at > the time of its request, the request must clearly describe and justify > why a larger allocation is required. > > All research allocations must be registered publicly in whois. Each > research allocation will be designated as a research allocation with a > comment indicating when the allocation will end. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else: > _______________________________________________ > 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: Tue, 08 Jul 2014 16:39:37 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 Message-ID: <53BC8139.6060803 at matthew.at> Content-Type: text/plain; charset=windows-1252; format=flowed Support. Making it easier for people to receive the last of the IPv4 pool is a good thing. Matthew Kaufman ------------------------------ Message: 6 Date: Tue, 08 Jul 2014 16:41:52 -0700 From: Matthew Kaufman > To: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations Message-ID: <53BC81C0.5050409 at matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Support. Even when DNS software bugs made it critical for ARIN and its predecessors to do their best, this has never been effectively implemented. The good news is that the bugs were fixed as a result, and so this is now a non-issue. Also, generally support removing extraneous language from NRPM. Matthew Kaufman ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 109, Issue 4 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From jcurran at arin.net Sun Jul 13 08:47:20 2014 From: jcurran at arin.net (John Curran) Date: Sun, 13 Jul 2014 12:47:20 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.com> <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> Message-ID: <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> On Jul 12, 2014, at 10:02 AM, Kevin Blumberg > wrote: Steven, I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. Correct. An updated staff assessment is forthcoming which adds the sentence: "If implemented, staff would continue using these well established criteria and guidelines for initial requests larger than /24." FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Sun Jul 13 13:39:27 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sun, 13 Jul 2014 17:39:27 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. That is part of the reason why I suggested changing 2014-13 to specify a range rather than a fixed allocation. I would be fine with having this proposal included with 2014-13 if the AC though that made sense. Otherwise it can remain separate. TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments 2. Proposal Originator a. name: Steven Ryerse b. email: SRyerse at eclipse-networks.com c. telephone: 770.656.1460 (c) 770.399.9099 (w) d. organization: Eclipse Networks Inc. 3. Date: 06-JUN-2014 4. Problem Statement: New and small organizations are having a difficult time receiving resource allocations from ARIN because of the economic, administrative and time burdens of making their way through ARIN's needs testing process. For small allocations, the burdens of needs testing may exceed the value of the resources, or may deter small, less well-funded organizations' ability to receive an allocation from ARIN. As ARIN was created to provide Internet resources to ALL organizations within its geographic territory, this disparity in the Policy Manual needs to be addressed. The problem can be remedied by removing needs testing for any organization that applies to receive the current minimum block size allocation. 5. Policy statement: "A Minimum IP allocation size(s) has been defined per Section 4 of the ARIN Number Resource Policy Manual. Regardless of any policy requirement(s) defined in any other active Section of the Policy Manual, all organizations may apply and shall automatically qualify for the current Minimum IP Block Allocation upon completing the normal administrative application process and fee requirements, and all organizations shall be eligible for such an allocation once every 12 months. Where this is in conflict with any other Section in the Policy Manual, this Section shall be controlling." 6. Comments: a. Timetable for implementation: Immediate b. Anything else: Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, July 13, 2014 8:47 AM To: Kevin Blumberg Cc: Steven Ryerse; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 On Jul 12, 2014, at 10:02 AM, Kevin Blumberg > wrote: Steven, I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. Correct. An updated staff assessment is forthcoming which adds the sentence: "If implemented, staff would continue using these well established criteria and guidelines for initial requests larger than /24." FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From gary.buhrmaster at gmail.com Sun Jul 13 14:37:59 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 13 Jul 2014 18:37:59 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> Message-ID: On Sun, Jul 13, 2014 at 5:39 PM, Steven Ryerse wrote: > > Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. I appears to me that your objection to this proposal is essentially IFF your proposed policy change to remove needs testing is accepted by the community, that accepting this proposal as written will mean you could only get a /24 without proving needs, rather than something larger. Is that the essence of your objection? If not, please be explicit, since I am not getting it. I would propose that if your goal is to be able to get a /22 (or whatever it is) every year without needs testing that you make that explicit in your new proposal. That way, the proposals are not interlinked in either way, and each can stand on their own merits, and the agenda's are (more) clearly marketed. Thanks. Gary From jcurran at arin.net Sun Jul 13 14:54:18 2014 From: jcurran at arin.net (John Curran) Date: Sun, 13 Jul 2014 18:54:18 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> Message-ID: On Jul 13, 2014, at 1:39 PM, Steven Ryerse > wrote: Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. Steven - That may be the case (that 2014-13 would complicate your policy proposal), but that is not equivalent to "making it harder for Organizations to get blocks that are larger than a /24". As far as the staff can determine, 2014-13 will not impact ability for parties to obtain larger blocks, as the established criteria and guidelines for initial requests larger than /24 will still be used. It would definitely allow issuance of address space (of /24 size) to organizations that would presently not qualify under current number resource policy. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Sun Jul 13 15:06:22 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sun, 13 Jul 2014 19:06:22 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local><4F8E DEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net><5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B364117@ENI-MAIL.eclipse-networks.com> Gary?s suggestion notwithstanding, if 2014-13 goes thru and then my proposal were to go thru, all that would have been accomplished would be that a /24 could be allocated without needs tests once per year. While that would slightly better than it is today, a /24 will only help the smallest of Organizations. I don?t want to see the Organizations that need the size of a /22 or a /24 to find it harder to get an allocation because of 2014-13 and if the needs test remain that is exactly what would happen. As I?ve said many times before the existing policies are stacked against small Organizations and I?m trying to remedy the inequity of that. In my view 2014-13 in its current form makes the problem worse and not better and I cannot support it in its current form. I would however support it if the language is changed to use a range of /20 down to /24 where the current policy says /20, and a range of /22 down to a /24 where the current policy says a /22. John I think it would be a great thing for you and the board to finally acknowledge that it is harder for a small Organization to get an allocation than larger ones and it is inherently unfair - and this Community need to address that inequity. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, July 13, 2014 2:54 PM To: Steven Ryerse Cc: Kevin Blumberg; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 On Jul 13, 2014, at 1:39 PM, Steven Ryerse > wrote: Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. Steven - That may be the case (that 2014-13 would complicate your policy proposal), but that is not equivalent to "making it harder for Organizations to get blocks that are larger than a /24". As far as the staff can determine, 2014-13 will not impact ability for parties to obtain larger blocks, as the established criteria and guidelines for initial requests larger than /24 will still be used. It would definitely allow issuance of address space (of /24 size) to organizations that would presently not qualify under current number resource policy. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From SRyerse at eclipse-networks.com Sun Jul 13 15:14:48 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sun, 13 Jul 2014 19:14:48 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.loc al><4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net><5B9E90747FA2974D91A 54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36414D@ENI-MAIL.eclipse-networks.com> I do think the Community needs to set the Minimums in various policies and I'm not trying to take that away. You are correct that my opinion is that if 2014-13 goes thru and then my proposed policy were to go thru then all that has been achieved is that a /24 could be had by all without needs testing once per year. Saddling an Organization that needs say a /20 with having to get disparate /24 blocks over times makes the problem worse for the slightly larger Organizations. We have seen that problem described recently by Larry Ash in his challenge to get a block large enough for his Organization's needs. I suppose that if 2014-13 does goes thru as is I will have to modify my proposed policy, but it would be great if the Community would finally come together and rectify these problems for smaller Organizations that have been described here by various Organizations from time to time for many years. 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: Gary Buhrmaster [mailto:gary.buhrmaster at gmail.com] Sent: Sunday, July 13, 2014 2:38 PM To: Steven Ryerse Cc: John Curran; Kevin Blumberg; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 On Sun, Jul 13, 2014 at 5:39 PM, Steven Ryerse wrote: > > Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. I appears to me that your objection to this proposal is essentially IFF your proposed policy change to remove needs testing is accepted by the community, that accepting this proposal as written will mean you could only get a /24 without proving needs, rather than something larger. Is that the essence of your objection? If not, please be explicit, since I am not getting it. I would propose that if your goal is to be able to get a /22 (or whatever it is) every year without needs testing that you make that explicit in your new proposal. That way, the proposals are not interlinked in either way, and each can stand on their own merits, and the agenda's are (more) clearly marketed. Thanks. Gary From info at arin.net Mon Jul 14 14:53:15 2014 From: info at arin.net (ARIN) Date: Mon, 14 Jul 2014 14:53:15 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised Message-ID: <53C4271B.8040403@arin.net> Draft Policy ARIN-2014-17 Change Utilization Requirements from last-allocation to total-aggregate ARIN-2014-17 has been revised. Draft Policy ARIN-2014-17 is below and can be found at: https://www.arin.net/policy/proposals/2014_17.html You are encouraged to discuss the merits and your concerns of Draft Policy 2014-17 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-2014-17 Change Utilization Requirements from last-allocation to total-aggregate Date: 14 July 2014 Problem Statement: Current ARIN policy calculates utilization on a per allocation basis rather than in aggregate. This method of determining utilization may cause some organizations to be unable to qualify for additional address blocks despite attempting to use their resource allocations as best as possible. This issue has been exacerbated in the past couple of years due to the 3-month allocation window which causes organizations to receive smaller non-expandable allocations rather than a larger aggregate. For example, if an organization has 4 x /22 and 3 of them are utilized 100% and the fourth utilized at 75%, an additional allocation request would be denied. However, an organization with a single /20 utilized at 80% would have less efficient utilization but would be eligible to receive additional space. Policy statement: Update Section 4.2.4.1 ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% in order to receive additional space. This includes all space reassigned to their customers. Update Section 4.3.6.1 End-users must have efficiently utilized all assignments, in aggregate, to at least 80% in order to receive additional space, and must provide ARIN with utilization details. Comments: a. Timetable for implementation: Immediate b. From David.Huberman at microsoft.com Mon Jul 14 15:00:54 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 14 Jul 2014 19:00:54 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C4271B.8040403@arin.net> References: <53C4271B.8040403@arin.net> Message-ID: <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> So I don't get something: If it's 80% overall, wouldn't this have an affect on of many XL networks, almost all of whom would be immediately eligible for more space even though they weren't eligible previously? I feel like in missing something. David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) ________________________________________ From: arin-ppml-bounces at arin.net on behalf of ARIN Sent: Monday, July 14, 2014 11:53:15 AM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised Draft Policy ARIN-2014-17 Change Utilization Requirements from last-allocation to total-aggregate ARIN-2014-17 has been revised. Draft Policy ARIN-2014-17 is below and can be found at: https://www.arin.net/policy/proposals/2014_17.html You are encouraged to discuss the merits and your concerns of Draft Policy 2014-17 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-2014-17 Change Utilization Requirements from last-allocation to total-aggregate Date: 14 July 2014 Problem Statement: Current ARIN policy calculates utilization on a per allocation basis rather than in aggregate. This method of determining utilization may cause some organizations to be unable to qualify for additional address blocks despite attempting to use their resource allocations as best as possible. This issue has been exacerbated in the past couple of years due to the 3-month allocation window which causes organizations to receive smaller non-expandable allocations rather than a larger aggregate. For example, if an organization has 4 x /22 and 3 of them are utilized 100% and the fourth utilized at 75%, an additional allocation request would be denied. However, an organization with a single /20 utilized at 80% would have less efficient utilization but would be eligible to receive additional space. Policy statement: Update Section 4.2.4.1 ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% in order to receive additional space. This includes all space reassigned to their customers. Update Section 4.3.6.1 End-users must have efficiently utilized all assignments, in aggregate, to at least 80% in order to receive additional space, and must provide ARIN with utilization details. Comments: a. Timetable for implementation: Immediate b. _______________________________________________ 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 scottleibrand at gmail.com Mon Jul 14 15:07:33 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 14 Jul 2014 12:07:33 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: For that reason, I personally would not support advancing this proposal in its current form until after ARIN free-pool run-out. After that time, I think it makes perfect sense to allow anyone, large or small, to get more space via transfer in order to get up to a 20% buffer. -Scott On Mon, Jul 14, 2014 at 12:00 PM, David Huberman < David.Huberman at microsoft.com> wrote: > So I don't get something: > > If it's 80% overall, wouldn't this have an affect on of many XL networks, > almost all of whom would be immediately eligible for more space even though > they weren't eligible previously? > > I feel like in missing something. > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf > of ARIN > Sent: Monday, July 14, 2014 11:53:15 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization > Requirements from last-allocation to total-aggregate - revised > > Draft Policy ARIN-2014-17 > Change Utilization Requirements from last-allocation to total-aggregate > > ARIN-2014-17 has been revised. > > Draft Policy ARIN-2014-17 is below and can be found at: > https://www.arin.net/policy/proposals/2014_17.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2014-17 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-2014-17 > Change Utilization Requirements from last-allocation to total-aggregate > > Date: 14 July 2014 > > Problem Statement: > > Current ARIN policy calculates utilization on a per allocation basis > rather than in aggregate. This method of determining utilization may > cause some organizations to be unable to qualify for additional address > blocks despite attempting to use their resource allocations as best as > possible. This issue has been exacerbated in the past couple of years > due to the 3-month allocation window which causes organizations to > receive smaller non-expandable allocations rather than a larger aggregate. > > For example, if an organization has 4 x /22 and 3 of them are utilized > 100% and the fourth utilized at 75%, an additional allocation request > would be denied. However, an organization with a single /20 utilized at > 80% would have less efficient utilization but would be eligible to > receive additional space. > > Policy statement: > > Update Section 4.2.4.1 > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% in order to receive additional space. This includes all space > reassigned to their customers. > > Update Section 4.3.6.1 > > End-users must have efficiently utilized all assignments, in aggregate, > to at least 80% in order to receive additional space, and must provide > ARIN with utilization details. > > Comments: > a. Timetable for implementation: Immediate > b. > _______________________________________________ > 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 bill at herrin.us Mon Jul 14 15:10:44 2014 From: bill at herrin.us (William Herrin) Date: Mon, 14 Jul 2014 15:10:44 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: On Mon, Jul 14, 2014 at 3:00 PM, David Huberman wrote: > If it's 80% overall, wouldn't this have an affect on > of many XL networks, almost all of whom would be > immediately eligible for more space even though > they weren't eligible previously? Might be the opposite. According to the current policy, allocations other than the most recent must have been "efficiently utilized" but need not currently be "at least 80%." "ISPs must have efficiently utilized all previous allocations and at least 80% of their most recent allocation in order to receive additional space." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From gary.buhrmaster at gmail.com Mon Jul 14 15:21:13 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 14 Jul 2014 19:21:13 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: On Jul 14, 2014 7:02 PM, "David Huberman" wrote: > > So I don't get something: > > If it's 80% overall, wouldn't this have an affect on of many XL networks, almost all of whom would be immediately eligible for more space even though they weren't eligible previously? > > I feel like in missing something. No, I think you have it. The issue this proposal tries to fix for some smaller networks has the (I presume) unintended side effect of letting $megaisp$ acquire additional numbers immediately. Perhaps some contorted language could "fix" that without other side effects, but the edges get complicated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Mon Jul 14 15:34:28 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 14 Jul 2014 12:34:28 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <53C430C4.9000602@matthew.at> On 7/14/2014 12:21 PM, Gary Buhrmaster wrote: > > > On Jul 14, 2014 7:02 PM, "David Huberman" > > > wrote: > > > > So I don't get something: > > > > If it's 80% overall, wouldn't this have an affect on of many XL > networks, almost all of whom would be immediately eligible for more > space even though they weren't eligible previously? > > > > I feel like in missing something. > > No, I think you have it. The issue this proposal tries to fix for > some smaller networks has the (I presume) unintended side effect of > letting $megaisp$ acquire additional numbers immediately. Perhaps > some contorted language could "fix" that without other side effects, > but the edges get complicated. > > Deck chairs, Titanic. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From derekc at cnets.net Mon Jul 14 15:52:55 2014 From: derekc at cnets.net (Derek Calanchini) Date: Mon, 14 Jul 2014 12:52:55 -0700 Subject: [arin-ppml] Minimum Allocation In-Reply-To: <53C430C4.9000602@matthew.at> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C430C4.9000602@matthew.at> Message-ID: <53C43517.7070806@cnets.net> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cnslogo1.bmp Type: image/bmp Size: 72774 bytes Desc: not available URL: From jeffrey.lyon at blacklotus.net Mon Jul 14 18:45:47 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 15 Jul 2014 07:45:47 +0900 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: Correct, this proposal makes more small networks with fragmented networks eligible to request space. It does nothing for large networks. Thanks, Jeff On Tue, Jul 15, 2014 at 4:21 AM, Gary Buhrmaster wrote: > > On Jul 14, 2014 7:02 PM, "David Huberman" > wrote: >> >> So I don't get something: >> >> If it's 80% overall, wouldn't this have an affect on of many XL networks, >> almost all of whom would be immediately eligible for more space even though >> they weren't eligible previously? >> >> I feel like in missing something. > > No, I think you have it. The issue this proposal tries to fix for some > smaller networks has the (I presume) unintended side effect of letting > $megaisp$ acquire additional numbers immediately. Perhaps some contorted > language could "fix" that without other side effects, but the edges get > complicated. > > > _______________________________________________ > 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. -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From andrew.dul at quark.net Mon Jul 14 20:30:29 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 14 Jul 2014 17:30:29 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <53C47625.6090407@quark.net> Jeff, I respectfully disagree with your assessment of this draft policy. The draft policy as written applies to all organizations which receive space from ARIN and would change how utilization is calculated for organizations which receive space as end-users or ISPs regardless of size. Andrew On 7/14/2014 3:45 PM, Jeffrey Lyon wrote: > Correct, this proposal makes more small networks with fragmented > networks eligible to request space. It does nothing for large > networks. > > Thanks, Jeff > > On Tue, Jul 15, 2014 at 4:21 AM, Gary Buhrmaster > wrote: >> On Jul 14, 2014 7:02 PM, "David Huberman" >> wrote: >>> So I don't get something: >>> >>> If it's 80% overall, wouldn't this have an affect on of many XL networks, >>> almost all of whom would be immediately eligible for more space even though >>> they weren't eligible previously? >>> >>> I feel like in missing something. >> No, I think you have it. The issue this proposal tries to fix for some >> smaller networks has the (I presume) unintended side effect of letting >> $megaisp$ acquire additional numbers immediately. Perhaps some contorted >> language could "fix" that without other side effects, but the edges get >> complicated. >> >> >> _______________________________________________ >> 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 jeffrey.lyon at blacklotus.net Mon Jul 14 21:06:18 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 15 Jul 2014 10:06:18 +0900 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C47625.6090407@quark.net> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> Message-ID: Andrew, It applies to all but is of zero benefit to large orgs with contiguous space. This idea that it allows big orgs to horde space is a red herring. Thanks, Jeff On Jul 15, 2014 9:30 AM, "Andrew Dul" wrote: > Jeff, > > I respectfully disagree with your assessment of this draft policy. The > draft policy as written applies to all organizations which receive space > from ARIN and would change how utilization is calculated for > organizations which receive space as end-users or ISPs regardless of size. > > Andrew > > On 7/14/2014 3:45 PM, Jeffrey Lyon wrote: > > Correct, this proposal makes more small networks with fragmented > > networks eligible to request space. It does nothing for large > > networks. > > > > Thanks, Jeff > > > > On Tue, Jul 15, 2014 at 4:21 AM, Gary Buhrmaster > > wrote: > >> On Jul 14, 2014 7:02 PM, "David Huberman" > > >> wrote: > >>> So I don't get something: > >>> > >>> If it's 80% overall, wouldn't this have an affect on of many XL > networks, > >>> almost all of whom would be immediately eligible for more space even > though > >>> they weren't eligible previously? > >>> > >>> I feel like in missing something. > >> No, I think you have it. The issue this proposal tries to fix for some > >> smaller networks has the (I presume) unintended side effect of letting > >> $megaisp$ acquire additional numbers immediately. Perhaps some > contorted > >> language could "fix" that without other side effects, but the edges get > >> complicated. > >> > >> > >> _______________________________________________ > >> 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 Mon Jul 14 21:44:24 2014 From: jcurran at arin.net (John Curran) Date: Tue, 15 Jul 2014 01:44:24 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> Message-ID: <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> On Jul 14, 2014, at 9:06 PM, Jeffrey Lyon > wrote: It applies to all but is of zero benefit to large orgs with contiguous space. This idea that it allows big orgs to horde space is a red herring. Jeffrey - For sake of argument, imagine a large ISP which over the course of time has ended up with a /8, two /16, and a /14 IPv4 blocks (with the /14 being the most recently issued block because of nearly full utilization of all prior blocks at the time.) Under present policy, the ISP cannot request address space until they have brought the utilization of the most recently issued block (the /14) up to 80%. Under the proposed policy, the ISP is immediately eligible to request space, since their aggregate utilization (even with a completely unused /14) is going to be very high (potentially as much as 97% due to the fully-used /8 block.) The proposed policy allows organizations to request space so long as their aggregate utilization is higher than 80%, and this means many existing organization with large IPv4 holdings will suddenly qualify to receive an additional allocation if they choose to request it. Whether that is desirable or not is a matter for the community to decide. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Mon Jul 14 22:08:15 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 14 Jul 2014 21:08:15 -0500 Subject: [arin-ppml] Minimum Allocation In-Reply-To: <53C43517.7070806@cnets.net> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C430C4.9000602@matthew.at> <53C43517.7070806@cnets.net> Message-ID: On Mon, Jul 14, 2014 at 2:52 PM, Derek Calanchini wrote: > Hi folks, > If you need a /22 from ARIN today and it's your first allocation, then your best bet is going to be to be multihomed and therefore have the /22 minimum apply naturally. The proposition to change the minimum is 2014-13, was still only a draft policy; subject to discussion under last call until Jul 15. If it becomes acceptabed, then, eventually ARIN should implement the new policy, but that is in the future, and certainly nothing you can reliably count on today and now. Has there been any movement on changing the minimum allocation? I still > need a /22 and am just wondering how I will know when that policy has > changed so I can resubmit my request.... > > > Best regards, > Derek Calanchini > -- -JH -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Mon Jul 14 22:24:55 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 15 Jul 2014 11:24:55 +0900 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> Message-ID: John, It is still a non-issue as they're only going to get a 3 month supply, which pales in comparison to the space they actually have available. The administrative overhead of making this request is highly prohibitive. Thanks, Jef On Tue, Jul 15, 2014 at 10:44 AM, John Curran wrote: > On Jul 14, 2014, at 9:06 PM, Jeffrey Lyon > wrote: > > It applies to all but is of zero benefit to large orgs with contiguous > space. This idea that it allows big orgs to horde space is a red herring. > > Jeffrey - > > For sake of argument, imagine a large ISP which over the course of time > has > ended up with a /8, two /16, and a /14 IPv4 blocks (with the /14 being the > most > recently issued block because of nearly full utilization of all prior > blocks at the > time.) > > Under present policy, the ISP cannot request address space until they have > brought the utilization of the most recently issued block (the /14) up to > 80%. > > Under the proposed policy, the ISP is immediately eligible to request > space, > since their aggregate utilization (even with a completely unused /14) is > going > to be very high (potentially as much as 97% due to the fully-used /8 > block.) > > The proposed policy allows organizations to request space so long as their > aggregate utilization is higher than 80%, and this means many existing > organization with large IPv4 holdings will suddenly qualify to receive an > additional allocation if they choose to request it. Whether that is > desirable > or not is a matter for the community to decide. > > FYI, > /John > > John Curran > President and CEO > ARIN > > -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From jcurran at arin.net Mon Jul 14 22:48:58 2014 From: jcurran at arin.net (John Curran) Date: Tue, 15 Jul 2014 02:48:58 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> Message-ID: On Jul 14, 2014, at 10:24 PM, Jeffrey Lyon wrote: > It is still a non-issue as they're only going to get a 3 month supply, > which pales in comparison to the space they actually have available. > The administrative overhead of making this request is highly > prohibitive. That may be the case; it depends on additional factors such how well organized the ISP is with respect to their address block recordkeeping, cost of obtaining address space on the transfer market, etc. The proposal would make it possible for some ISPs (large and small) to request additional space who may not otherwise be able due to difficulty in reaching full utilization of past address blocks. For larger ISP's, there is potentially diminishing returns given that there is significant documentation necessary regarding the utilization of all their previous allocations (However, this is slightly offset as their utilization rate is higher, therefore providing a larger relatively-sized block allocation based on their 3 month usage..) Hope this helps, /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Mon Jul 14 22:51:48 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 15 Jul 2014 11:51:48 +0900 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> Message-ID: John, With that said, small ISP's have much to gain with this proposal and large ISP's, very little. Thanks, Jeff On Tue, Jul 15, 2014 at 11:48 AM, John Curran wrote: > On Jul 14, 2014, at 10:24 PM, Jeffrey Lyon wrote: >> It is still a non-issue as they're only going to get a 3 month supply, >> which pales in comparison to the space they actually have available. >> The administrative overhead of making this request is highly >> prohibitive. > > That may be the case; it depends on additional factors such how well > organized the ISP is with respect to their address block recordkeeping, > cost of obtaining address space on the transfer market, etc. > > The proposal would make it possible for some ISPs (large and small) to > request additional space who may not otherwise be able due to difficulty > in reaching full utilization of past address blocks. > > For larger ISP's, there is potentially diminishing returns given that > there is significant documentation necessary regarding the utilization > of all their previous allocations (However, this is slightly offset > as their utilization rate is higher, therefore providing a larger > relatively-sized block allocation based on their 3 month usage..) > > Hope this helps, > /John > > John Curran > President and CEO > ARIN > -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From michael at linuxmagic.com Tue Jul 15 11:02:37 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 15 Jul 2014 08:02:37 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> Message-ID: <53C5428D.80306@linuxmagic.com> Hi John, My biggest argument against this is that this encourages abusive squandering of IP space, in order to get more. Especially for anyone who wants to own as much as possible 'real estate'. Ie an operator can use this as a vehicle, say they get a /16. Their mandate is then to fill it up as fast as possible. So they 'rent' space to anyone they can, eg affiliate email marketers, or any use that can sneak by being recognized as 'used'. Hit 80% aggregate and you get more, rent it out... (it doesn't even matter if it is done profitably, that isn't the goal here) With diminishing IP Space, if there was some way to set standards on what usage qualifies on 80% usage, I could get behind it. But we are already seeing what appears to be this activity amongst hosters ("..get it used, I don't care what for..") I know, I can't think of a way to set those standards that the community can get behind, so I am sure ARIN can't ;) All I am saying, is that anything that encourages or allows for the larger players to 'land grab' isnt' in the best interests of the community either. I think that this will encourage the incumbants, at the expense of new entrants, and those looking to 'land grab' more than the existing policies, and thus I am against this policy change. However, we don't want to disadvantage someone just because they have been successful either. I think we need another idea to come up.. > Jeffrey - > For sake of argument, imagine a large ISP which over the course of > time has > ended up with a /8, two /16, and a /14 IPv4 blocks (with the /14 > being the most > recently issued block because of nearly full utilization of all prior > blocks at the > time.) > Under present policy, the ISP cannot request address space until they > have > brought the utilization of the most recently issued block (the /14) > up to 80%. > Under the proposed policy, the ISP is immediately eligible to request > space, > since their aggregate utilization (even with a completely unused /14) > is going > to be very high (potentially as much as 97% due to the fully-used /8 > block.) > > The proposed policy allows organizations to request space so long as > their > aggregate utilization is higher than 80%, and this means many existing > organization with large IPv4 holdings will suddenly qualify to > receive an > additional allocation if they choose to request it. Whether that is > desirable > or not is a matter for the community to decide. > > FYI, > /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. > -- "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 matthew at matthew.at Tue Jul 15 13:04:42 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 15 Jul 2014 10:04:42 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> Message-ID: <53C55F2A.7010105@matthew.at> On 7/14/2014 6:44 PM, John Curran wrote: > On Jul 14, 2014, at 9:06 PM, Jeffrey Lyon > wrote: >> >> It applies to all but is of zero benefit to large orgs with >> contiguous space. This idea that it allows big orgs to horde space is >> a red herring. >> > Jeffrey - > For sake of argument, imagine a large ISP which over the course of > time has > ended up with a /8, two /16, and a /14 IPv4 blocks (with the /14 > being the most > recently issued block because of nearly full utilization of all > prior blocks at the > time.) > Under present policy, the ISP cannot request address space until > they have > brought the utilization of the most recently issued block (the /14) > up to 80%. > Under the proposed policy, the ISP is immediately eligible to > request space, > since their aggregate utilization (even with a completely unused > /14) is going > to be very high (potentially as much as 97% due to the fully-used /8 > block.) > > The proposed policy allows organizations to request space so long as > their > aggregate utilization is higher than 80%, and this means many existing > organization with large IPv4 holdings will suddenly qualify to > receive an > additional allocation if they choose to request it. Whether that is > desirable > or not is a matter for the community to decide. > > Your theoretical argument assumes a certain kind of large ISP. Let me propose a couple of alternative scenarios: Imagine a large ISP which over the course of time has ended up with a /8, two /16, and a /14 block with the /14 being the most recently issued block. Under present policy, they cannot get more space until the /14 is documented at 80% utilization, which they've got the documentation all ready for. Under the proposed policy, the ISP can't get any space, because their recordkeeping on the /8 is terrible. They got the /8 and the /16 pre-ARIN, probably as two different entities than the one that got the /14, and now instead of submitting the detailed documentation they started keeping not long after they got that second /16 (so they could get the /14, and so they could get more when the /14 filled) they'd need to spend more time and effort than they have to dredge up utilization records for that /8 just to get another 3 months worth of space from ARIN (even though the scrap papers laying around and the routing tables strongly suggest that all that space really is in use, and isn't easily reclaimed to meet their pressing need). So they get nothing. Or imagine a large ISP which over the course of time has ended up with a /8, two /16 and a /14 with the /14 being the most recently issued block. Under present policy, they cannot get more space until the /14 is documented at 80% utilization, and they're all ready to do that. Under the proposed policy, the ISP can't get any space because while they've got great records for how the /8 and the two /16s are utilized, the customer and internal assignments they did back then are deemed to be inefficient by ARIN staff when they review the utilization records for everything. All those point-to-point links using whole /24s, and dialup pools that are sized for what was needed back in the days of dialup but nowadays only have a handful of customers on them aren't ok any more. So instead of being able to just pounce on some space because of this policy change, they're actually blocked from getting more. Overall, I think the answer is that for certain kinds of ISPs in certain kinds of growth patterns, the change in policy would make it easier for them to qualify. But for many others, it would make it harder. I am not in favor of pulling the rug out from under people at the last minute, and given how close we are to runout it would be exactly that to change IPv4 policy on them. So I oppose this policy as written, and any other attempts to make last-minute changes. For people who've planned ahead, stability is the best we can give them. For people who haven't planned ahead, they're screwed whether we change the policy or not. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Tue Jul 15 13:28:35 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 15 Jul 2014 10:28:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C55F2A.7010105@matthew.at> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C55F2A.7010105@matthew.at> Message-ID: <53C564C3.2010909@quark.net> On 7/15/2014 10:04 AM, Matthew Kaufman wrote: > On 7/14/2014 6:44 PM, John Curran wrote: >> On Jul 14, 2014, at 9:06 PM, Jeffrey Lyon >> > wrote: >>> >>> It applies to all but is of zero benefit to large orgs with >>> contiguous space. This idea that it allows big orgs to horde space >>> is a red herring. >>> >> Jeffrey - >> >> For sake of argument, imagine a large ISP which over the course of >> time has >> ended up with a /8, two /16, and a /14 IPv4 blocks (with the /14 >> being the most >> recently issued block because of nearly full utilization of all >> prior blocks at the >> time.) >> >> Under present policy, the ISP cannot request address space until >> they have >> brought the utilization of the most recently issued block (the /14) >> up to 80%. >> >> Under the proposed policy, the ISP is immediately eligible to >> request space, >> since their aggregate utilization (even with a completely unused >> /14) is going >> to be very high (potentially as much as 97% due to the fully-used >> /8 block.) >> >> The proposed policy allows organizations to request space so long >> as their >> aggregate utilization is higher than 80%, and this means many existing >> organization with large IPv4 holdings will suddenly qualify to >> receive an >> additional allocation if they choose to request it. Whether that >> is desirable >> or not is a matter for the community to decide. >> >> > > Your theoretical argument assumes a certain kind of large ISP. Let me > propose a couple of alternative scenarios: > > Imagine a large ISP which over the course of time has ended up with a > /8, two /16, and a /14 block with the /14 being the most recently > issued block. > > Under present policy, they cannot get more space until the /14 is > documented at 80% utilization, which they've got the documentation all > ready for. > > Under the proposed policy, the ISP can't get any space, because their > recordkeeping on the /8 is terrible. They got the /8 and the /16 > pre-ARIN, probably as two different entities than the one that got the > /14, and now instead of submitting the detailed documentation they > started keeping not long after they got that second /16 (so they could > get the /14, and so they could get more when the /14 filled) they'd > need to spend more time and effort than they have to dredge up > utilization records for that /8 just to get another 3 months worth of > space from ARIN (even though the scrap papers laying around and the > routing tables strongly suggest that all that space really is in use, > and isn't easily reclaimed to meet their pressing need). So they get > nothing. > > Or imagine a large ISP which over the course of time has ended up with > a /8, two /16 and a /14 with the /14 being the most recently issued block. > > Under present policy, they cannot get more space until the /14 is > documented at 80% utilization, and they're all ready to do that. > > Under the proposed policy, the ISP can't get any space because while > they've got great records for how the /8 and the two /16s are > utilized, the customer and internal assignments they did back then are > deemed to be inefficient by ARIN staff when they review the > utilization records for everything. All those point-to-point links > using whole /24s, and dialup pools that are sized for what was needed > back in the days of dialup but nowadays only have a handful of > customers on them aren't ok any more. So instead of being able to just > pounce on some space because of this policy change, they're actually > blocked from getting more. > > Overall, I think the answer is that for certain kinds of ISPs in > certain kinds of growth patterns, the change in policy would make it > easier for them to qualify. But for many others, it would make it harder. > > I am not in favor of pulling the rug out from under people at the last > minute, and given how close we are to runout it would be exactly that > to change IPv4 policy on them. So I oppose this policy as written, and > any other attempts to make last-minute changes. For people who've > planned ahead, stability is the best we can give them. For people who > haven't planned ahead, they're screwed whether we change the policy or > not. Matthew, Thank you for your detailed explanation of your arguments against this policy as written. Would you support this policy after the free pool has been exhausted? Some have suggested that this type of policy also eases the transfer market because it refocuses an organization on their entire address holdings and gives them a potentially larger buffer than they could carry previously. Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Jul 15 13:35:21 2014 From: jcurran at arin.net (John Curran) Date: Tue, 15 Jul 2014 17:35:21 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C55F2A.7010105@matthew.at> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C55F2A.7010105@matthew.at> Message-ID: <15B30383-43FA-4351-B09D-C4E7BAFB3BC9@corp.arin.net> On Jul 15, 2014, at 1:04 PM, Matthew Kaufman wrote: > > Your theoretical argument assumes a certain kind of large ISP. Agreed, but I'm not certain it is theoretical given that any larger ISP that has received a request recently has already had to get record-keeping in order in order to qualify for that last assignment (and we've had several recent large allocations as noted in the arin-issued reports) > Let me propose a couple of alternative scenarios: > > Imagine a large ISP which over the course of time has ended up with a /8, two /16, and a /14 block with the /14 being the most recently issued block. > > Under present policy, they cannot get more space until the /14 is documented at 80% utilization, which they've got the documentation all ready for. > > Under the proposed policy, the ISP can't get any space, because their recordkeeping on the /8 is terrible. They got the /8 and the /16 pre-ARIN, probably as two different entities than the one that got the /14, and now instead of submitting the detailed documentation they started keeping not long after they got that second /16 (so they could get the /14, and so they could get more when the /14 filled) they'd need to spend more time and effort than they have to dredge up utilization records for that /8 just to get another 3 months worth of space from ARIN (even though the scrap papers laying around and the routing tables strongly suggest that all that space really is in use, and isn't easily reclaimed to meet their pressing need). So they get nothing. Quite possible that this could occur for some ISPs, with the result being no effective improvement in ability to obtain another allocation. > Or imagine a large ISP which over the course of time has ended up with a /8, two /16 and a /14 with the /14 being the most recently issued block. > > Under present policy, they cannot get more space until the /14 is documented at 80% utilization, and they're all ready to do that. > > Under the proposed policy, the ISP can't get any space because while they've got great records for how the /8 and the two /16s are utilized, the customer and internal assignments they did back then are deemed to be inefficient by ARIN staff when they review the utilization records for everything. All those point-to-point links using whole /24s, and dialup pools that are sized for what was needed back in the days of dialup but nowadays only have a handful of customers on them aren't ok any more. So instead of being able to just pounce on some space because of this policy change, they're actually blocked from getting more. They still had to supply the same information (to show that the prior blocks are fully utilized per present policy) so the above scenario is invalid. This makes sense, as the policy change with regard to the aggregate utilization level and not definitions of how utilization is determined for specific technologies (as per your example) > Overall, I think the answer is that for certain kinds of ISPs in certain kinds of growth patterns, the change in policy would make it easier for them to qualify. Yes. > But for many others, it would make it harder. See above; if the intent of the policy proposal is to make it harder, then the policy text should be made more explicit regarding the desired changes in policy. Thanks! /John John Curran President and CEO ARIN From gdendy at equinix.com Wed Jul 16 00:32:04 2014 From: gdendy at equinix.com (Greg Dendy) Date: Tue, 15 Jul 2014 21:32:04 -0700 Subject: [arin-ppml] NANOG 62 - Baltimore - Call For Presentations is Open! In-Reply-To: <180F02C2-7158-4843-A43D-4CF7AA941A20@equinix.com> References: <180F02C2-7158-4843-A43D-4CF7AA941A20@equinix.com> Message-ID: <7B5E480D-AC08-49FD-A167-7F2098A358D2@equinix.com> The presentation submission period for NANOG 62 is still open, although the deadline is fast approaching. It's not too late to join what's shaping up to be a great program! Thanks, Greg -- Greg Dendy Chair, Program Committee North American Network Operator Group (NANOG) On Jun 16, 2014, at 9:31 PM, Greg Dendy > wrote: NANOG Community- Thanks for helping to make NANOG 61 in Bellevue such a smashing success as the most attended meeting ever, on the 20th anniversary of the first meeting! NANOG will hold its 62nd meeting in Baltimore, MD on October 6-8, 2014, hosted by EdgeConneX. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 62 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet, . Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. Key dates to track if you wish to submit a presentation: * Presentation Abstracts and Draft Slides Due: August 4, 2014 * Topic List Posted: August 18, 2014 * Slides Due: September 1, 2014 * Agenda Published: September 15, 2014 NANOG 62 submissions are welcome on the Program Committee Site or email me if you have questions. Looking forward to seeing everyone in Baltimore! Thanks, Greg Dendy Chair, Program Committee North American Network Operator Group (NANOG) -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jul 17 05:27:21 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 02:27:21 -0700 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks.c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> Message-ID: <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> Member of the AC hat on (though not speaking on behalf of the AC): If this proposal gains traction and 2014-13 is adopted, the AC and the community can make the necessary adjustments to it in light of 2014-13 if 2014-13 is adopted. Changing 2014-13 so substantially at this time would only serve to delay its potential implementation without actually benefiting this proposal. If such a range is desired to go with this proposal, the necessary changes can be added to this proposal without significant difficulty. AC hat off -- Speaking only as myself and a member of the community at large: I fail to see the logic in establishing a "minimum range". A minimum is just that... A minimum. Anything larger than the minimum is not the minimum, so a minimum range is a minimum and some other numbers that happen to be larger than the minimum. Even if 2014-13 were somehow modified and we were able to work past the lexical cognitive dissonance inherent in the idea of a "minimum range", I don't see how this proposal would work without significant modification to deal with the issue of how a request is mapped to a particular "minimum" within the "minimum range" that applies by as yet unspecified criteria. Perhaps if you could clarify how you see this idea of a "minimum range" working and how it could actually be implemented or what it is you hope having such a thing would provide that the existing policy and/or 2014-13 does not provide, it would be helpful. Owen On Jul 13, 2014, at 10:39 , Steven Ryerse wrote: > Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. That is part of the reason why I suggested changing 2014-13 to specify a range rather than a fixed allocation. I would be fine with having this proposal included with 2014-13 if the AC though that made sense. Otherwise it can remain separate. > > > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 > > 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments > > 2. Proposal Originator > a. name: Steven Ryerse > b. email: SRyerse at eclipse-networks.com > c. telephone: 770.656.1460 (c) 770.399.9099 (w) > d. organization: Eclipse Networks Inc. > > 3. Date: 06-JUN-2014 > > 4. Problem Statement: > > New and small organizations are having a difficult time receiving > resource allocations from ARIN because of the economic, administrative > and time burdens of making their way through ARIN's needs testing > process. For small allocations, the burdens of needs testing may > exceed the value of the resources, or may deter small, less > well-funded organizations' ability to receive an allocation from ARIN. > As ARIN was created to provide Internet resources to ALL organizations > within its geographic territory, this disparity in the Policy Manual > needs to be addressed. The problem can be remedied by removing needs > testing for any organization that applies to receive the current > minimum block size allocation. > > > 5. Policy statement: > > "A Minimum IP allocation size(s) has been defined per Section 4 of > the ARIN Number Resource Policy Manual. Regardless of any policy > requirement(s) defined in any other active Section of the Policy > Manual, all organizations may apply and shall automatically qualify > for the current Minimum IP Block Allocation upon completing the > normal administrative application process and fee requirements, and > all organizations shall be eligible for such an allocation once > every 12 months. Where this is in conflict with any other Section > in the Policy Manual, this Section shall be controlling." > > > 6. Comments: > a. Timetable for implementation: Immediate > b. Anything else: > > > > 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? > > From: John Curran [mailto:jcurran at arin.net] > Sent: Sunday, July 13, 2014 8:47 AM > To: Kevin Blumberg > Cc: Steven Ryerse; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN 2014-13 > > On Jul 12, 2014, at 10:02 AM, Kevin Blumberg wrote: > > > Steven, > > I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. > > In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. > > Correct. An updated staff assessment is forthcoming which adds the sentence: > > "If implemented, staff would continue using these well established criteria and > guidelines for initial requests larger than /24." > > FYI, > /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 owen at delong.com Thu Jul 17 06:23:26 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 03:23:26 -0700 Subject: [arin-ppml] Minimum Allocation In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C430C4.9000602@matthew.at> <53C43517.7070806@cnets.net> Message-ID: <0B1B6EE7-486D-4979-B056-B5224B7D13B3@delong.com> To clarify: Details here: https://www.arin.net/policy/proposals/2014_13.html 2014-13 is a Recommended Draft Policy which was brought for Adoption Discussion at the PPC at NANOG Seattle. The AC put it to Last Call in their June meeting and that last call ended two days ago on July 15th. The AC will meet today and will discuss the results of last call. Possible outcomes include: 1. Recommend Adoption to the Board, in which case, the proposal leaves the AC and goes to the Board of Trustees for final ratification and then staff for implementation. 2. Continue working on the policy (revert it to draft policy). 3. Abandon the policy. It would be inappropriate (and just as likely inaccurate) for me to speculate on what the full AC will do, but I will be supporting a motion to send this to the board for ratification. I believe the results of the AC meeting will be published early next week. Owen On Jul 14, 2014, at 19:08 , Jimmy Hess wrote: > On Mon, Jul 14, 2014 at 2:52 PM, Derek Calanchini wrote: > Hi folks, > > If you need a /22 from ARIN today and it's your first allocation, then your best bet is going to be to be multihomed and therefore have the /22 minimum apply naturally. > > The proposition to change the minimum is 2014-13, was still only a draft policy; subject to discussion under last call until Jul 15. If it becomes acceptabed, then, eventually ARIN should implement the new policy, but that is in the future, and certainly nothing you can reliably count on today and now. > > > Has there been any movement on changing the minimum allocation? I still need a /22 and am just wondering how I will know when that policy has changed so I can resubmit my request.... > > > Best regards, > Derek Calanchini > > -- > -JH > _______________________________________________ > 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 Thu Jul 17 06:56:44 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 03:56:44 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C5428D.80306@linuxmagic.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> Message-ID: On Jul 15, 2014, at 08:02 , Michael Peddemors wrote: > Hi John, > > My biggest argument against this is that this encourages abusive squandering of IP space, in order to get more. Especially for anyone who wants to own as much as possible 'real estate'. > > Ie an operator can use this as a vehicle, say they get a /16. Their mandate is then to fill it up as fast as possible. So they 'rent' space to anyone they can, eg affiliate email marketers, or any use that can sneak by being recognized as 'used'. > > Hit 80% aggregate and you get more, rent it out... (it doesn't even matter if it is done profitably, that isn't the goal here) Can you explain how this is different under current policy? It seems to me that the issue you describe is unchanged between the current policy and the draft policy considered in this thread. Do you have suggestions on how this issue could be addressed without making it overly difficult to qualify for address space in general? > With diminishing IP Space, if there was some way to set standards on what usage qualifies on 80% usage, I could get behind it. To be clear, the current policy is also 80%. The difference is that current policy requires 80% of your last block and "efficient utilization" of all other blocks (which is vaguely or not at all defined). The proposed policy is to change that to 80% of all blocks in aggregate. > But we are already seeing what appears to be this activity amongst hosters ("..get it used, I don't care what for..") > > I know, I can't think of a way to set those standards that the community can get behind, so I am sure ARIN can't ;) > > All I am saying, is that anything that encourages or allows for the larger players to 'land grab' isnt' in the best interests of the community either. I don't believe this proposal carries significant large-carrier land-grab potential. It does carry some small theoretical land grab capability as mentioned earlier, but when you look at the reality, it doesn't allow a very large amount of space to be obtained by a larger provider. Further, most large providers could probably move a little bit of internal stuff around and make the numbers work to qualify for much larger requests than this would allow under current policy. > I think that this will encourage the incumbants, at the expense of new entrants, and those looking to 'land grab' more than the existing policies, and thus I am against this policy change. I think it will have exactly the opposite effect, actually. I think it lowers the barrier for smaller entities and new entrants while keeping roughly the same effective requirements for larger incumbents. > However, we don't want to disadvantage someone just because they have been successful either. It is important to keep policy fair and technically sound. I don't believe that this proposal would disadvantage anyone. > > I think we need another idea to come up.. Such as? Not to put too fine a point on it, but there are a number of smaller organizations that are really suffering from the current situation and this proposal would be a huge help to them. If you've got an alternative solution, then by all means, let's hear it. Otherwise, I think moving this one forward does more good than harm. Owen From michael at linuxmagic.com Thu Jul 17 11:05:58 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 17 Jul 2014 08:05:58 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> Message-ID: <53C7E656.6050602@linuxmagic.com> On 14-07-17 03:56 AM, Owen DeLong wrote: > > Do you have suggestions on how this issue could be addressed without making it overly difficult to qualify for address space in general? No, I am putting thought into it, but no magic bullets yet.. just think this isn't the one.. > >> With diminishing IP Space, if there was some way to set standards on what usage qualifies on 80% usage, I could get behind it. > > To be clear, the current policy is also 80%. The difference is that current policy requires 80% of your last block and "efficient utilization" of all other blocks (which is vaguely or not at all defined). > > The proposed policy is to change that to 80% of all blocks in aggregate. Totally understood of course.. I believe this will make it easier to abuse the system. IMHO > I think it will have exactly the opposite effect, actually. I think it lowers the barrier for smaller entities and new entrants while keeping roughly the same effective requirements for larger incumbents. Maybe if you can show how the barriers are reduced for smaller entities and new entrants, vs how they will be affected if the larger entities are enabled to get the remaining space faster? >> I think we need another idea to come up.. > > Such as? Hopefully the question will be answered, and the quicker we move on, maybe the quicker that will be answered. > > Not to put too fine a point on it, but there are a number of smaller organizations that are really suffering from the current situation and this proposal would be a huge help to them. If you've got an alternative solution, then by all means, let's hear it. Otherwise, I think moving this one forward does more good than harm. Okay, please show how this is the case? -- "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 mike at iptrading.com Thu Jul 17 11:35:23 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 17 Jul 2014 11:35:23 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C7E656.6050602@linuxmagic.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net><53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> Message-ID: > I think it will have exactly the opposite effect, actually. I think it > lowers the barrier for smaller entities and new entrants while keeping > roughly the same effective requirements for larger incumbents. Maybe if you can show how the barriers are reduced for smaller entities and new entrants, vs how they will be affected if the larger entities are enabled to get the remaining space faster? >> I think we need another idea to come up.. > > Such as? Hopefully the question will be answered, and the quicker we move on, maybe the quicker that will be answered. How about support for removing the needs test for small transfers a la 2014-14? It seems to benefit those whose needs are small, but who are having difficulties with justification due to niggling IPv4 policy issues like minimum sizes and utilization requirements. Others have noted we are rearranging the deck chairs on the Titanic with these IPv4 policy issues. Maybe it is time to metaphorically sweep those chairs into the sea so we can move on. Regards, Mike From SRyerse at eclipse-networks.com Thu Jul 17 11:54:06 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 17 Jul 2014 15:54:06 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change UtilizationRequirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM 2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F 75408CC5AB@corp.arin.net><53C5428D.80306@linuxmagic.com><53C7E656.6050602@linuxmagic.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36AA61@ENI-MAIL.eclipse-networks.com> I agree. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 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 Mike Burns Sent: Thursday, July 17, 2014 11:35 AM To: Michael Peddemors; Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2014-17: Change UtilizationRequirements from last-allocation to total-aggregate - revised > I think it will have exactly the opposite effect, actually. I think it > lowers the barrier for smaller entities and new entrants while keeping > roughly the same effective requirements for larger incumbents. Maybe if you can show how the barriers are reduced for smaller entities and new entrants, vs how they will be affected if the larger entities are enabled to get the remaining space faster? >> I think we need another idea to come up.. > > Such as? Hopefully the question will be answered, and the quicker we move on, maybe the quicker that will be answered. How about support for removing the needs test for small transfers a la 2014-14? It seems to benefit those whose needs are small, but who are having difficulties with justification due to niggling IPv4 policy issues like minimum sizes and utilization requirements. Others have noted we are rearranging the deck chairs on the Titanic with these IPv4 policy issues. Maybe it is time to metaphorically sweep those chairs into the sea so we can move on. Regards, Mike _______________________________________________ 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 gary.buhrmaster at gmail.com Thu Jul 17 12:28:16 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 17 Jul 2014 16:28:16 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> Message-ID: On Thu, Jul 17, 2014 at 3:35 PM, Mike Burns wrote: .... > Others have noted we are rearranging the deck chairs on the Titanic with > these IPv4 policy issues. > Maybe it is time to metaphorically sweep those chairs into the sea so we can > move on. Perhaps that is an interesting idea. Remove needs testing for IPv6 /48s, and let everyone move on to being able to access all of the Internet. I would have to consider the other implications, but I think I could get behind removing needs testing for /48's given how large the remaining IPv6 address space is, and it would be an interesting experiment and insure that there is absolutely no reason that one cannot move to IPv6 now. From SRyerse at eclipse-networks.com Thu Jul 17 13:29:52 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 17 Jul 2014 17:29:52 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change UtilizationRequirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net><98e34c256f3e4402a2b3a5aab5d3f841@DM2 PR03MB398.namprd03.prod.outlook.com><53C47625.6090407@quark.net><329F6ABF-5623-4469-B9EC-0F75408 CC5AB@corp.arin.net><53C5428D.80306@linuxmagic.com><53C7E656.6050602@linuxmagic.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36ACBC@ENI-MAIL.eclipse-networks.com> I would support. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 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 Gary Buhrmaster Sent: Thursday, July 17, 2014 12:28 PM To: Mike Burns Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2014-17: Change UtilizationRequirements from last-allocation to total-aggregate - revised On Thu, Jul 17, 2014 at 3:35 PM, Mike Burns wrote: .... > Others have noted we are rearranging the deck chairs on the Titanic > with these IPv4 policy issues. > Maybe it is time to metaphorically sweep those chairs into the sea so > we can move on. Perhaps that is an interesting idea. Remove needs testing for IPv6 /48s, and let everyone move on to being able to access all of the Internet. I would have to consider the other implications, but I think I could get behind removing needs testing for /48's given how large the remaining IPv6 address space is, and it would be an interesting experiment and insure that there is absolutely no reason that one cannot move to IPv6 now. _______________________________________________ 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 Thu Jul 17 15:05:23 2014 From: jschiller at google.com (Jason Schiller) Date: Thu, 17 Jul 2014 15:05:23 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> Message-ID: On Thu, Jul 17, 2014 at 11:35 AM, Mike Burns wrote: | Maybe it is time to metaphorically sweep those chairs into the sea so we can move on. You mean like give exactly one /24 to each person who posts to this thread until there are none left? I think the last time that was proposed a lot of people posted to the thread but most said "I oppose, but if this does pass, consider me in line for a /24". Maybe the community feels different now? Personally, I think it is increasingly more important to provide stewardship and ensure IP addresses go to those that need it as the resource becomes more scarce and more costly. __Jason On Thu, Jul 17, 2014 at 11:35 AM, Mike Burns wrote: > > I think it will have exactly the opposite effect, actually. I think it >> lowers the barrier for smaller entities and new entrants while keeping >> roughly the same effective requirements for larger incumbents. >> > > Maybe if you can show how the barriers are reduced for smaller entities > and new entrants, vs how they will be affected if the larger entities > are enabled to get the remaining space faster? > > > I think we need another idea to come up.. >>> >> >> Such as? >> > > Hopefully the question will be answered, and the quicker we move on, > maybe the quicker that will be answered. > > > > How about support for removing the needs test for small transfers a la > 2014-14? > It seems to benefit those whose needs are small, but who are having > difficulties with justification due to niggling IPv4 policy issues like > minimum sizes and utilization requirements. > Others have noted we are rearranging the deck chairs on the Titanic with > these IPv4 policy issues. > Maybe it is time to metaphorically sweep those chairs into the sea so we > can move on. > > Regards, > Mike > > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Thu Jul 17 15:12:35 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 17 Jul 2014 19:12:35 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks. c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36AEDD@ENI-MAIL.eclipse-networks.com> Owen, I think you usually advocate getting it right instead of getting it fast and I would prefer to get it right on this one for sure. Maybe it would be a good idea to solicit input now from this Community for a change in 2014-13 to a Range vs. just a /24. My two cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, July 17, 2014 5:27 AM To: Steven Ryerse Cc: John Curran; Kevin Blumberg; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 Member of the AC hat on (though not speaking on behalf of the AC): If this proposal gains traction and 2014-13 is adopted, the AC and the community can make the necessary adjustments to it in light of 2014-13 if 2014-13 is adopted. Changing 2014-13 so substantially at this time would only serve to delay its potential implementation without actually benefiting this proposal. If such a range is desired to go with this proposal, the necessary changes can be added to this proposal without significant difficulty. AC hat off -- Speaking only as myself and a member of the community at large: I fail to see the logic in establishing a "minimum range". A minimum is just that... A minimum. Anything larger than the minimum is not the minimum, so a minimum range is a minimum and some other numbers that happen to be larger than the minimum. Even if 2014-13 were somehow modified and we were able to work past the lexical cognitive dissonance inherent in the idea of a "minimum range", I don't see how this proposal would work without significant modification to deal with the issue of how a request is mapped to a particular "minimum" within the "minimum range" that applies by as yet unspecified criteria. Perhaps if you could clarify how you see this idea of a "minimum range" working and how it could actually be implemented or what it is you hope having such a thing would provide that the existing policy and/or 2014-13 does not provide, it would be helpful. Owen On Jul 13, 2014, at 10:39 , Steven Ryerse > wrote: Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. That is part of the reason why I suggested changing 2014-13 to specify a range rather than a fixed allocation. I would be fine with having this proposal included with 2014-13 if the AC though that made sense. Otherwise it can remain separate. TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments 2. Proposal Originator a. name: Steven Ryerse b. email: SRyerse at eclipse-networks.com c. telephone: 770.656.1460 (c) 770.399.9099 (w) d. organization: Eclipse Networks Inc. 3. Date: 06-JUN-2014 4. Problem Statement: New and small organizations are having a difficult time receiving resource allocations from ARIN because of the economic, administrative and time burdens of making their way through ARIN's needs testing process. For small allocations, the burdens of needs testing may exceed the value of the resources, or may deter small, less well-funded organizations' ability to receive an allocation from ARIN. As ARIN was created to provide Internet resources to ALL organizations within its geographic territory, this disparity in the Policy Manual needs to be addressed. The problem can be remedied by removing needs testing for any organization that applies to receive the current minimum block size allocation. 5. Policy statement: "A Minimum IP allocation size(s) has been defined per Section 4 of the ARIN Number Resource Policy Manual. Regardless of any policy requirement(s) defined in any other active Section of the Policy Manual, all organizations may apply and shall automatically qualify for the current Minimum IP Block Allocation upon completing the normal administrative application process and fee requirements, and all organizations shall be eligible for such an allocation once every 12 months. Where this is in conflict with any other Section in the Policy Manual, this Section shall be controlling." 6. Comments: a. Timetable for implementation: Immediate b. Anything else: 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? From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, July 13, 2014 8:47 AM To: Kevin Blumberg Cc: Steven Ryerse; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 On Jul 12, 2014, at 10:02 AM, Kevin Blumberg > wrote: Steven, I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. Correct. An updated staff assessment is forthcoming which adds the sentence: "If implemented, staff would continue using these well established criteria and guidelines for initial requests larger than /24." FYI, /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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From michael at linuxmagic.com Thu Jul 17 15:15:34 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 17 Jul 2014 12:15:34 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> Message-ID: <53C820D6.3040305@linuxmagic.com> On 14-07-17 12:05 PM, Jason Schiller wrote: > increasingly more important to provide stewardship and ensure IP addresses go to those that need it as the resource becomes more scarce and more costly. Ay, there's the rub.. How do you create a working proposal that will be accepted by all to mandate that stewardship, and how do we set the guidelines.. Many of the other proposals are in place, because we haven't been able to come up with a working idea for that envisioned utopia -- "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 owen at delong.com Thu Jul 17 19:59:44 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 16:59:44 -0700 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36AEDD@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks. c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36AEDD@ENI-MAIL.eclipse-networks.com> Message-ID: Point is that the current proposal which just concluded last call definitely gets it better than the current circumstance. If the community decides to develop your proposal, we can always add the pieces needed to integrate it. In short, we can get 2014-13 right and right now, and we can, if there is consensus, get your proposal right later. Putting 2014-13 in place as is does nothing to harm that process and it provides much needed relief to a number of organizations sooner rather than later. I'm at a bit of a disadvantage in commenting further as I am not at liberty to disclose the AC actions today. However, irrespective of what actually happened, I think it is a good idea not to delay 2014-13 for the sake of possibly improving how it integrates with your proposal. Instead, we can make all the necessary changes under the banner of your proposal, if it gains traction with the community. In short, it's no less right to adopt 2014-13 as is and just make the changes in your proposal later. There's absolutely no harm and significant benefit. Owen On Jul 17, 2014, at 12:12 , Steven Ryerse wrote: > Owen, I think you usually advocate getting it right instead of getting it fast and I would prefer to get it right on this one for sure. Maybe it would be a good idea to solicit input now from this Community for a change in 2014-13 to a Range vs. just a /24. My two cents. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, July 17, 2014 5:27 AM > To: Steven Ryerse > Cc: John Curran; Kevin Blumberg; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN 2014-13 > > Member of the AC hat on (though not speaking on behalf of the AC): > > If this proposal gains traction and 2014-13 is adopted, the AC and the community can make the necessary adjustments to it in light of 2014-13 if 2014-13 is adopted. > > Changing 2014-13 so substantially at this time would only serve to delay its potential implementation without actually benefiting this proposal. If such a range is desired to go with this proposal, the necessary changes can be added to this proposal without significant difficulty. > > AC hat off -- Speaking only as myself and a member of the community at large: > > I fail to see the logic in establishing a "minimum range". A minimum is just that... A minimum. Anything larger than the minimum is not the minimum, so a minimum range is a minimum and some other numbers that happen to be larger than the minimum. > > Even if 2014-13 were somehow modified and we were able to work past the lexical cognitive dissonance inherent in the idea of a "minimum range", I don't see how this proposal would work without significant modification to deal with the issue of how a request is mapped to a particular "minimum" within the "minimum range" that applies by as yet unspecified criteria. > > Perhaps if you could clarify how you see this idea of a "minimum range" working and how it could actually be implemented or what it is you hope having such a thing would provide that the existing policy and/or 2014-13 does not provide, it would be helpful. > > Owen > > On Jul 13, 2014, at 10:39 , Steven Ryerse wrote: > > > Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. That is part of the reason why I suggested changing 2014-13 to specify a range rather than a fixed allocation. I would be fine with having this proposal included with 2014-13 if the AC though that made sense. Otherwise it can remain separate. > > > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 > > 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments > > 2. Proposal Originator > a. name: Steven Ryerse > b. email: SRyerse at eclipse-networks.com > c. telephone: 770.656.1460 (c) 770.399.9099 (w) > d. organization: Eclipse Networks Inc. > > 3. Date: 06-JUN-2014 > > 4. Problem Statement: > > New and small organizations are having a difficult time receiving > resource allocations from ARIN because of the economic, administrative > and time burdens of making their way through ARIN's needs testing > process. For small allocations, the burdens of needs testing may > exceed the value of the resources, or may deter small, less > well-funded organizations' ability to receive an allocation from ARIN. > As ARIN was created to provide Internet resources to ALL organizations > within its geographic territory, this disparity in the Policy Manual > needs to be addressed. The problem can be remedied by removing needs > testing for any organization that applies to receive the current > minimum block size allocation. > > > 5. Policy statement: > > "A Minimum IP allocation size(s) has been defined per Section 4 of > the ARIN Number Resource Policy Manual. Regardless of any policy > requirement(s) defined in any other active Section of the Policy > Manual, all organizations may apply and shall automatically qualify > for the current Minimum IP Block Allocation upon completing the > normal administrative application process and fee requirements, and > all organizations shall be eligible for such an allocation once > every 12 months. Where this is in conflict with any other Section > in the Policy Manual, this Section shall be controlling." > > > 6. Comments: > a. Timetable for implementation: Immediate > b. Anything else: > > > > 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? > > From: John Curran [mailto:jcurran at arin.net] > Sent: Sunday, July 13, 2014 8:47 AM > To: Kevin Blumberg > Cc: Steven Ryerse; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN 2014-13 > > On Jul 12, 2014, at 10:02 AM, Kevin Blumberg wrote: > > > > Steven, > > I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. > > In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. > > Correct. An updated staff assessment is forthcoming which adds the sentence: > > "If implemented, staff would continue using these well established criteria and > guidelines for initial requests larger than /24." > > FYI, > /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 owen at delong.com Thu Jul 17 20:13:16 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 17:13:16 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C7E656.6050602@linuxmagic.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> Message-ID: <28C108BD-61A4-4B54-9367-859BBD13391E@delong.com> >> To be clear, the current policy is also 80%. The difference is that current policy requires 80% of your last block and "efficient utilization" of all other blocks (which is vaguely or not at all defined). >> >> The proposed policy is to change that to 80% of all blocks in aggregate. > > Totally understood of course.. I believe this will make it easier to abuse the system. IMHO If so, only by a very marginal amount. Especially when you consider the 3-month limit now in place. >> I think it will have exactly the opposite effect, actually. I think it lowers the barrier for smaller entities and new entrants while keeping roughly the same effective requirements for larger incumbents. > > Maybe if you can show how the barriers are reduced for smaller entities and new entrants, vs how they will be affected if the larger entities are enabled to get the remaining space faster? Asked and answered earlier in the thread, but I will give it a shot... If you have a collection of smaller blocks, it is much harder to get to 80% utilization in each one while still preserving contiguous free space to accommodate a larger-than-normal customer or a surge in customers. For example, if you have 3 /22s and have utilized all but a /26, three discontiguous /27s, and a two discontiguous /28s and a couple of /29s of the last one and all but a /29 of each of the other two and you have a customer come in who needs a /24, you're stuck. You need to find some other customer with a smaller need or some valid utilization for a small block or two in order to reach your 80% utilization on that last block. OTOH, if you look at your overall situation, you're well past 80% overall. This is not an uncommon scenario (in various forms) for small providers. The rules as they exist were written with minimum allocations of /20 and larger in mind at the time and smaller organizations mostly did not receive space directly from ARIN. This has evolved over time and this part of policy has failed to keep up. >>> I think we need another idea to come up.. >> >> Such as? > > Hopefully the question will be answered, and the quicker we move on, maybe the quicker that will be answered. We can agree to disagree. I think if we have a solution available that improves the situation for a number of community members while only offering a small potential for increased abuse (there are actually much easier ways to abuse the system if one desires to do so and they would yield much more address space), that we should do what we can until a better solution comes along. >> Not to put too fine a point on it, but there are a number of smaller organizations that are really suffering from the current situation and this proposal would be a huge help to them. If you've got an alternative solution, then by all means, let's hear it. Otherwise, I think moving this one forward does more good than harm. > > Okay, please show how this is the case? See above. It's a rather contrived example, but the real world is much messier and much harder to explain in detail. Also, I don't happen to be working for such a provider at the moment, so I don't have a factual detailed account to present, but I assure you I have seen many of these first hand over the years. Owen From owen at delong.com Thu Jul 17 20:14:15 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 17:14:15 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net><53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> Message-ID: On Jul 17, 2014, at 08:35 , Mike Burns wrote: > >> I think it will have exactly the opposite effect, actually. I think it lowers the barrier for smaller entities and new entrants while keeping roughly the same effective requirements for larger incumbents. > > Maybe if you can show how the barriers are reduced for smaller entities > and new entrants, vs how they will be affected if the larger entities > are enabled to get the remaining space faster? > > >>> I think we need another idea to come up.. >> >> Such as? > > Hopefully the question will be answered, and the quicker we move on, > maybe the quicker that will be answered. > > > > How about support for removing the needs test for small transfers a la 2014-14? > It seems to benefit those whose needs are small, but who are having difficulties with justification due to niggling IPv4 policy issues like minimum sizes and utilization requirements. > Others have noted we are rearranging the deck chairs on the Titanic with these IPv4 policy issues. > Maybe it is time to metaphorically sweep those chairs into the sea so we can move on. At the moment, that seems to me like the implementation of a small-tax. Owen From owen at delong.com Thu Jul 17 20:31:08 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 17:31:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> Message-ID: <05AE2807-C76E-4210-8776-168CFE065E4D@delong.com> On Jul 17, 2014, at 09:28 , Gary Buhrmaster wrote: > On Thu, Jul 17, 2014 at 3:35 PM, Mike Burns wrote: > .... >> Others have noted we are rearranging the deck chairs on the Titanic with >> these IPv4 policy issues. >> Maybe it is time to metaphorically sweep those chairs into the sea so we can >> move on. > > Perhaps that is an interesting idea. Remove needs testing for > IPv6 /48s, and let everyone move on to being able to access > all of the Internet. I would have to consider the other implications, > but I think I could get behind removing needs testing for /48's > given how large the remaining IPv6 address space is, and it > would be an interesting experiment and insure that there is > absolutely no reason that one cannot move to IPv6 now. I don't support removing needs testing for IPv6 /48s at this time, but I will point out that the existing needs test for IPv6 boils down to: 1. I have a site. 2. I want to connect that site to the internet. 3. The address for that site is within the ARIN region. 4. That site meets one or more of the following criteria: A) Already has IPv4 from ARIN (6.5.8.1.a) B) Will be multihomed (6.5.8.1.b) C) Will have 2000 host addresses in use within 12 months (6.5.8.1.c) D) Will have 200 subnets within 12 months (6.5.8.1.d) E) Has some other technical justification for needing a direct assignment rather than getting LIR assigned space (6.5.8.1.e) It's not quite a Pez dispenser, but it's about as close as I would be comfortable making it. From NRPM section 6.5.8: > 6.5.8.1. Initial Assignment Criteria > Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: > Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; > Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; > By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; > By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; > By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. This is the official wording, but I think I captured the essence above. Further, 6.5.8.1 goes on to provide several examples that should qualify under 6.5.8.1(e), so an inability to justify an IPv6 /48 for your site is, at this point, pretty much a failure of imagination or an impressively small site with no directly assigned IPv4 resources. Seriously, how hard is it to stand up 2000 interface addresses over the course of 12 months? If I _REALLY_ had to do this, I bet 15 minutes and a PERL script could do it on a single host. (No, I'm not advocating that, just pointing out that short of an incredibly silly trivial infrastructure, this is really a no-brainer). Remember, if you use privacy addressing, you're probably looking at 4-5 addresses per host minimum, depending on how you set your preferred and valid lifetimes and your refresh rate on rotating privacy addresses. So 2000 addresses is more like 400 active hosts, including all your routers, virtual machines, switches, web servers, etc. You can also allocate an IPv6 address to every service on a box if you want. (completely legitimate and good technical reasons to do so in some cases). 2000 host addresses is a _REALLY_ low barrier to entry, as is 200 subnets. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Thu Jul 17 20:42:41 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 17 Jul 2014 17:42:41 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <28C108BD-61A4-4B54-9367-859BBD13391E@delong.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> <28C108BD-61A4-4B54-9367-859BBD13391E@delong.com> Message-ID: <53C86D81.6070800@linuxmagic.com> On 14-07-17 05:13 PM, Owen DeLong wrote: > Asked and answered earlier in the thread, but I will give it a shot... > > If you have a collection of smaller blocks, it is much harder to get to 80% utilization in each one while still preserving contiguous free space to accommodate a larger-than-normal customer or a surge in customers. For example, if you have 3 /22s and have utilized all but a /26, three discontiguous /27s, and a two discontiguous /28s and a couple of /29s of the last one and all but a /29 of each of the other two and you have a customer come in who needs a /24, you're stuck. You need to find some other customer with a smaller need or some valid utilization for a small block or two in order to reach your 80% utilization on that last block. > > OTOH, if you look at your overall situation, you're well past 80% overall. > > This is not an uncommon scenario (in various forms) for small providers. The rules as they exist were written with minimum allocations of /20 and larger in mind at the time and smaller organizations mostly did not receive space directly from ARIN. Thanks Owen, And I guess maybe that helps define where you and me differ on this, this again seems to represent the scenario of a 'hoster' who ends up 'renting' out his IP(s) to other parties. I have to make an assumption that this is a lot rarer than you think, those entities get larger space. And where I have concern is for the small service operators who need that /24/23/22/21/20 for their own operations or business models or cloud services, but don't want to be beholding to any provider and want to 'own' their own IP Space. These are the ones that I think may suffer here, and they don't usually have a voice here.. and I am being a bit altruistic possibly, but I find it hard to support ideas which make things easier for those who want the 'real estate' value vs the end users of IP space. End users you can be sure will fill all the 'nooks and crannies' of their total space. And while your test case may not seem bad, when you look at those with /16/15/14/13../8 Those 'nooks and crannies' become large swathes that should be used up before they get more as we run low. The current policy helps to ensure that all the delegated space gets used first.. before giving an incumbant more .. again IMHO My two cents.. I want to see more full utilization before running out, (in the absense of ways and methods of 'stewardship' and priority on the types and validity of usage.) as a better chance that people in the future can still get some from ARIN for longer. -- "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 owen at delong.com Thu Jul 17 21:23:19 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jul 2014 18:23:19 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <53C86D81.6070800@linuxmagic.com> References: <53C4271B.8040403@arin.net> <98e34c256f3e4402a2b3a5aab5d3f841@DM2PR03MB398.namprd03.prod.outlook.com> <53C47625.6090407@quark.net> <329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net> <53C5428D.80306@linuxmagic.com> <53C7E656.6050602@linuxmagic.com> <28C108BD-61A4-4B54-9367-859BBD13391E@delong.com> <53C86D81.6070800@linuxmagic.com> Message-ID: On Jul 17, 2014, at 17:42 , Michael Peddemors wrote: > On 14-07-17 05:13 PM, Owen DeLong wrote: >> Asked and answered earlier in the thread, but I will give it a shot... >> >> If you have a collection of smaller blocks, it is much harder to get to 80% utilization in each one while still preserving contiguous free space to accommodate a larger-than-normal customer or a surge in customers. For example, if you have 3 /22s and have utilized all but a /26, three discontiguous /27s, and a two discontiguous /28s and a couple of /29s of the last one and all but a /29 of each of the other two and you have a customer come in who needs a /24, you're stuck. You need to find some other customer with a smaller need or some valid utilization for a small block or two in order to reach your 80% utilization on that last block. >> >> OTOH, if you look at your overall situation, you're well past 80% overall. >> >> This is not an uncommon scenario (in various forms) for small providers. The rules as they exist were written with minimum allocations of /20 and larger in mind at the time and smaller organizations mostly did not receive space directly from ARIN. > > Thanks Owen, > > And I guess maybe that helps define where you and me differ on this, this again seems to represent the scenario of a 'hoster' who ends up 'renting' out his IP(s) to other parties. How is that different from a rural residential provider who ends up selling to a combination of residential and business subscribers or even mostly business subscribers? Why is a hoster an invalid use of IP addresses? Colo and Datacenter operators have been ISPs in this region for a very long time now and I've worked for a few of them. It's at least part of what my current employer does. > I have to make an assumption that this is a lot rarer than you think, those entities get larger space. I have to say that you are very wrong there. Yes, there are entities that you are more likely to know that get larger space, but for every large entity that you know, there are literally hundreds of much smaller entities simply trying to get by in smaller markets, targeted market segments, and other vertical integration scenarios. The internet is a VERY diverse place and the small players outnumber the large ones by many orders of magnitude. > And where I have concern is for the small service operators who need that /24/23/22/21/20 for their own operations or business models or cloud services, but don't want to be beholding to any provider and want to 'own' their own IP Space. Those are "end users" in ARIN parlance and I don't think they would suffer under this policy. In fact, they would be largely unaffected by it. The only extent to which it might effect them is if it accelerates runout. I don't believe for a second that this proposal will represent a significant acceleration for runout beyond the satisfaction of long pent-up demand for addresses that has gone as yet unsatisfied due to policy quirks. I suppose if you want to protect some small to medium end-users at the expense of small ISPs and you consider that fair policy, there is little I can do to convince you otherwise. It seems quite unfair to me. I believe that small ISPs have just as much right to the address space as end users of any size. > These are the ones that I think may suffer here, and they don't usually have a voice here.. and I am being a bit altruistic possibly, but I find it hard to support ideas which make things easier for those who want the 'real estate' value vs the end users of IP space. I think that's a very jaded way to look at it and I don't consider this helping those that want the "real estate" value. Are you saying ARIN shouldn't issue space to ISPs at all and that end-users should get absolute priority over ISPs in general? If not, I am really having a hard time understanding the argument you are making here. > End users you can be sure will fill all the 'nooks and crannies' of their total space. And while your test case may not seem bad, when you look at those with /16/15/14/13../8 Those 'nooks and crannies' become large swathes that should be used up before they get more as we run low. Sure, but when you consider the three month maximum that those providers are facing, they won't get enough more to avoid filling up the nooks and crannies anyway, so I'm not thinking it really has as much of an effect as you seem to think. > The current policy helps to ensure that all the delegated space gets used first.. before giving an incumbant more .. again IMHO No, it actually doesn't. What it does, instead, is reward those who can renumber on a nimble basis and shove stuff into their most recent allocation while leaving larger holes in their earlier allocations. The proposal would actually require that ALL space is utilized to at least 80% while the current policy only requires a strict 80% on the most recently used block. > My two cents.. > > I want to see more full utilization before running out, (in the absense of ways and methods of 'stewardship' and priority on the types and validity of usage.) as a better chance that people in the future can still get some from ARIN for longer. I want to see more IPv6 deployment before running out. In reality, we'll both likely be disappointed in different ways. Owen From narten at us.ibm.com Fri Jul 18 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Jul 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201407180453.s6I4r3ej002532@rotala.raleigh.ibm.com> Total of 45 messages in the last 7 days. script run at: Fri Jul 18 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.78% | 8 | 20.16% | 153701 | owen at delong.com 13.33% | 6 | 17.95% | 136871 | sryerse at eclipse-networks.com 11.11% | 5 | 5.78% | 44060 | jcurran at arin.net 2.22% | 1 | 14.26% | 108701 | derekc at cnets.net 2.22% | 1 | 12.20% | 93017 | kevinb at thewire.ca 8.89% | 4 | 4.40% | 33569 | jeffrey.lyon at blacklotus.net 8.89% | 4 | 4.27% | 32537 | michael at linuxmagic.com 6.67% | 3 | 2.75% | 20989 | gary.buhrmaster at gmail.com 4.44% | 2 | 3.48% | 26522 | andrew.dul at quark.net 4.44% | 2 | 3.05% | 23230 | matthew at matthew.at 2.22% | 1 | 2.12% | 16181 | scottleibrand at gmail.com 2.22% | 1 | 1.97% | 15040 | gdendy at equinix.com 2.22% | 1 | 1.83% | 13938 | jschiller at google.com 2.22% | 1 | 1.22% | 9272 | david.huberman at microsoft.com 2.22% | 1 | 1.13% | 8607 | mysidia at gmail.com 2.22% | 1 | 0.90% | 6852 | info at arin.net 2.22% | 1 | 0.86% | 6551 | narten at us.ibm.com 2.22% | 1 | 0.85% | 6444 | bill at herrin.us 2.22% | 1 | 0.82% | 6244 | mike at iptrading.com --------+------+--------+----------+------------------------ 100.00% | 45 |100.00% | 762326 | Total From SRyerse at eclipse-networks.com Fri Jul 18 12:47:42 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 18 Jul 2014 16:47:42 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks. c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> While I am concerned that my policy proposal would be affected, my larger concern is that this policy will make it harder for smaller organizations in practice to receive allocations at the low end of the scale right above a /24. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, July 17, 2014 5:27 AM To: Steven Ryerse Cc: John Curran; Kevin Blumberg; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 Member of the AC hat on (though not speaking on behalf of the AC): If this proposal gains traction and 2014-13 is adopted, the AC and the community can make the necessary adjustments to it in light of 2014-13 if 2014-13 is adopted. Changing 2014-13 so substantially at this time would only serve to delay its potential implementation without actually benefiting this proposal. If such a range is desired to go with this proposal, the necessary changes can be added to this proposal without significant difficulty. AC hat off -- Speaking only as myself and a member of the community at large: I fail to see the logic in establishing a "minimum range". A minimum is just that... A minimum. Anything larger than the minimum is not the minimum, so a minimum range is a minimum and some other numbers that happen to be larger than the minimum. Even if 2014-13 were somehow modified and we were able to work past the lexical cognitive dissonance inherent in the idea of a "minimum range", I don't see how this proposal would work without significant modification to deal with the issue of how a request is mapped to a particular "minimum" within the "minimum range" that applies by as yet unspecified criteria. Perhaps if you could clarify how you see this idea of a "minimum range" working and how it could actually be implemented or what it is you hope having such a thing would provide that the existing policy and/or 2014-13 does not provide, it would be helpful. Owen On Jul 13, 2014, at 10:39 , Steven Ryerse > wrote: Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. That is part of the reason why I suggested changing 2014-13 to specify a range rather than a fixed allocation. I would be fine with having this proposal included with 2014-13 if the AC though that made sense. Otherwise it can remain separate. TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments 2. Proposal Originator a. name: Steven Ryerse b. email: SRyerse at eclipse-networks.com c. telephone: 770.656.1460 (c) 770.399.9099 (w) d. organization: Eclipse Networks Inc. 3. Date: 06-JUN-2014 4. Problem Statement: New and small organizations are having a difficult time receiving resource allocations from ARIN because of the economic, administrative and time burdens of making their way through ARIN's needs testing process. For small allocations, the burdens of needs testing may exceed the value of the resources, or may deter small, less well-funded organizations' ability to receive an allocation from ARIN. As ARIN was created to provide Internet resources to ALL organizations within its geographic territory, this disparity in the Policy Manual needs to be addressed. The problem can be remedied by removing needs testing for any organization that applies to receive the current minimum block size allocation. 5. Policy statement: "A Minimum IP allocation size(s) has been defined per Section 4 of the ARIN Number Resource Policy Manual. Regardless of any policy requirement(s) defined in any other active Section of the Policy Manual, all organizations may apply and shall automatically qualify for the current Minimum IP Block Allocation upon completing the normal administrative application process and fee requirements, and all organizations shall be eligible for such an allocation once every 12 months. Where this is in conflict with any other Section in the Policy Manual, this Section shall be controlling." 6. Comments: a. Timetable for implementation: Immediate b. Anything else: 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? From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, July 13, 2014 8:47 AM To: Kevin Blumberg Cc: Steven Ryerse; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 On Jul 12, 2014, at 10:02 AM, Kevin Blumberg > wrote: Steven, I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. Correct. An updated staff assessment is forthcoming which adds the sentence: "If implemented, staff would continue using these well established criteria and guidelines for initial requests larger than /24." FYI, /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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From cblecker at gmail.com Fri Jul 18 16:24:14 2014 From: cblecker at gmail.com (Christoph Blecker) Date: Fri, 18 Jul 2014 13:24:14 -0700 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> Message-ID: Hi Steven, To quote John earlier in this exact thread: As far as the staff can determine, 2014-13 will not impact ability for parties to obtain larger blocks, as the established criteria and guidelines for initial requests larger than /24 will still be used. It would definitely allow issuance of address space (of /24 size) to organizations that would presently not qualify under current number resource policy There doesn't seem to be any ambiguity in that. Is there anything you can provide this community to back up your concerns? Or does this remove any concerns you have? Cheers, Christoph On Fri, Jul 18, 2014 at 9:47 AM, Steven Ryerse wrote: > While I am concerned that my policy proposal would be affected, my > larger concern is that this policy will make it harder for smaller > organizations in practice to receive allocations at the low end of the > scale right above a /24. > > > > *Steven Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 <770.656.1460> - Cell* > > *770.399.9099 <770.399.9099>- Office* > > > > [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse > Networks, Inc. > > Conquering Complex Networks? > > > > *From:* Owen DeLong [mailto:owen at delong.com] > *Sent:* Thursday, July 17, 2014 5:27 AM > *To:* Steven Ryerse > *Cc:* John Curran; Kevin Blumberg; arin-ppml at arin.net > > *Subject:* Re: [arin-ppml] ARIN 2014-13 > > > > Member of the AC hat on (though not speaking on behalf of the AC): > > > > If this proposal gains traction and 2014-13 is adopted, the AC and the > community can make the necessary adjustments to it in light of 2014-13 if > 2014-13 is adopted. > > > > Changing 2014-13 so substantially at this time would only serve to delay > its potential implementation without actually benefiting this proposal. If > such a range is desired to go with this proposal, the necessary changes can > be added to this proposal without significant difficulty. > > > > AC hat off -- Speaking only as myself and a member of the community at > large: > > > > I fail to see the logic in establishing a "minimum range". A minimum is > just that... A minimum. Anything larger than the minimum is not the > minimum, so a minimum range is a minimum and some other numbers that happen > to be larger than the minimum. > > > > Even if 2014-13 were somehow modified and we were able to work past the > lexical cognitive dissonance inherent in the idea of a "minimum range", I > don't see how this proposal would work without significant modification to > deal with the issue of how a request is mapped to a particular "minimum" > within the "minimum range" that applies by as yet unspecified criteria. > > > > Perhaps if you could clarify how you see this idea of a "minimum range" > working and how it could actually be implemented or what it is you hope > having such a thing would provide that the existing policy and/or 2014-13 > does not provide, it would be helpful. > > > > Owen > > > > On Jul 13, 2014, at 10:39 , Steven Ryerse > wrote: > > > > Its more complicated than that. I?ve submitted the proposed policy > change below to the AC. Obviously at this early stage I don?t know if the > Community will accept this or not but 2014-13 complicates this proposal. > That is part of the reason why I suggested changing 2014-13 to specify a > range rather than a fixed allocation. I would be fine with having this > proposal included with 2014-13 if the AC though that made sense. Otherwise > it can remain separate. > > > > > > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 > > > > 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments > > > > 2. Proposal Originator > > a. name: Steven Ryerse > > b. email: SRyerse at eclipse-networks.com > > c. telephone: 770.656.1460 (c) 770.399.9099 (w) > > d. organization: Eclipse Networks Inc. > > > > 3. Date: 06-JUN-2014 > > > > 4. Problem Statement: > > > > New and small organizations are having a difficult time receiving > > resource allocations from ARIN because of the economic, administrative > > and time burdens of making their way through ARIN's needs testing > > process. For small allocations, the burdens of needs testing may > > exceed the value of the resources, or may deter small, less > > well-funded organizations' ability to receive an allocation from ARIN. > > As ARIN was created to provide Internet resources to ALL organizations > > within its geographic territory, this disparity in the Policy Manual > > needs to be addressed. The problem can be remedied by removing needs > > testing for any organization that applies to receive the current > > minimum block size allocation. > > > > > > 5. Policy statement: > > > > "A Minimum IP allocation size(s) has been defined per Section 4 of > > the ARIN Number Resource Policy Manual. Regardless of any policy > > requirement(s) defined in any other active Section of the Policy > > Manual, all organizations may apply and shall automatically qualify > > for the current Minimum IP Block Allocation upon completing the > > normal administrative application process and fee requirements, and > > all organizations shall be eligible for such an allocation once > > every 12 months. Where this is in conflict with any other Section > > in the Policy Manual, this Section shall be controlling." > > > > > > 6. Comments: > > a. Timetable for implementation: Immediate > > b. Anything else: > > > > > > > > *Steven Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *www.eclipse-networks.com * > > *770.656.1460 <770.656.1460> - Cell* > > *770.399.9099 <770.399.9099>- Office* > > > > ? Eclipse Networks, Inc. > > Conquering Complex Networks? > > > > *From:* John Curran [mailto:jcurran at arin.net ] > *Sent:* Sunday, July 13, 2014 8:47 AM > *To:* Kevin Blumberg > *Cc:* Steven Ryerse; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] ARIN 2014-13 > > > > On Jul 12, 2014, at 10:02 AM, Kevin Blumberg wrote: > > > > > Steven, > > > > I?ve double checked with staff and this proposal will not make allocations > or assignments larger than /24 more difficult than today. > > > > In the revised section 4.2.1.5 Minimum allocation the text allows for /24 > and larger prefixes, it isn?t limited to only a /24. > > > > Correct. An updated staff assessment is forthcoming which adds the > sentence: > > > > "If implemented, staff would continue using these well established > criteria and > > guidelines for initial requests larger than /24." > > > > FYI, > > /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. > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: not available URL: From owen at delong.com Fri Jul 18 18:57:09 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Jul 2014 15:57:09 -0700 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks. c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> Message-ID: <87ABC782-5999-460D-9DBF-8773C16C3344@delong.com> I can't help it if you choose to ignore the facts. Your concern has been repeatedly debunked by the AC, staff, and other members of the list. It simply isn't an accurate or valid concern. Anyone that can get a larger block now will still be able to get the same size block with the same effort if 2014-13 is implemented. All 2014-13 does is make it possible for people to get smaller blocks than were previously possible in some cases, enabling organizations that previously could not get any size block to now get some block. Owen On Jul 18, 2014, at 09:47 , Steven Ryerse wrote: > While I am concerned that my policy proposal would be affected, my larger concern is that this policy will make it harder for smaller organizations in practice to receive allocations at the low end of the scale right above a /24. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, July 17, 2014 5:27 AM > To: Steven Ryerse > Cc: John Curran; Kevin Blumberg; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN 2014-13 > > Member of the AC hat on (though not speaking on behalf of the AC): > > If this proposal gains traction and 2014-13 is adopted, the AC and the community can make the necessary adjustments to it in light of 2014-13 if 2014-13 is adopted. > > Changing 2014-13 so substantially at this time would only serve to delay its potential implementation without actually benefiting this proposal. If such a range is desired to go with this proposal, the necessary changes can be added to this proposal without significant difficulty. > > AC hat off -- Speaking only as myself and a member of the community at large: > > I fail to see the logic in establishing a "minimum range". A minimum is just that... A minimum. Anything larger than the minimum is not the minimum, so a minimum range is a minimum and some other numbers that happen to be larger than the minimum. > > Even if 2014-13 were somehow modified and we were able to work past the lexical cognitive dissonance inherent in the idea of a "minimum range", I don't see how this proposal would work without significant modification to deal with the issue of how a request is mapped to a particular "minimum" within the "minimum range" that applies by as yet unspecified criteria. > > Perhaps if you could clarify how you see this idea of a "minimum range" working and how it could actually be implemented or what it is you hope having such a thing would provide that the existing policy and/or 2014-13 does not provide, it would be helpful. > > Owen > > On Jul 13, 2014, at 10:39 , Steven Ryerse wrote: > > > Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. That is part of the reason why I suggested changing 2014-13 to specify a range rather than a fixed allocation. I would be fine with having this proposal included with 2014-13 if the AC though that made sense. Otherwise it can remain separate. > > > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 > > 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments > > 2. Proposal Originator > a. name: Steven Ryerse > b. email: SRyerse at eclipse-networks.com > c. telephone: 770.656.1460 (c) 770.399.9099 (w) > d. organization: Eclipse Networks Inc. > > 3. Date: 06-JUN-2014 > > 4. Problem Statement: > > New and small organizations are having a difficult time receiving > resource allocations from ARIN because of the economic, administrative > and time burdens of making their way through ARIN's needs testing > process. For small allocations, the burdens of needs testing may > exceed the value of the resources, or may deter small, less > well-funded organizations' ability to receive an allocation from ARIN. > As ARIN was created to provide Internet resources to ALL organizations > within its geographic territory, this disparity in the Policy Manual > needs to be addressed. The problem can be remedied by removing needs > testing for any organization that applies to receive the current > minimum block size allocation. > > > 5. Policy statement: > > "A Minimum IP allocation size(s) has been defined per Section 4 of > the ARIN Number Resource Policy Manual. Regardless of any policy > requirement(s) defined in any other active Section of the Policy > Manual, all organizations may apply and shall automatically qualify > for the current Minimum IP Block Allocation upon completing the > normal administrative application process and fee requirements, and > all organizations shall be eligible for such an allocation once > every 12 months. Where this is in conflict with any other Section > in the Policy Manual, this Section shall be controlling." > > > 6. Comments: > a. Timetable for implementation: Immediate > b. Anything else: > > > > 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? > > From: John Curran [mailto:jcurran at arin.net] > Sent: Sunday, July 13, 2014 8:47 AM > To: Kevin Blumberg > Cc: Steven Ryerse; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN 2014-13 > > On Jul 12, 2014, at 10:02 AM, Kevin Blumberg wrote: > > > > Steven, > > I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. > > In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. > > Correct. An updated staff assessment is forthcoming which adds the sentence: > > "If implemented, staff would continue using these well established criteria and > guidelines for initial requests larger than /24." > > FYI, > /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 SRyerse at eclipse-networks.com Fri Jul 18 19:42:30 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 18 Jul 2014 23:42:30 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <87ABC782-5999-460D-9DBF-8773C16C3344@delong.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015B3242DB@ENI-MAIL.eclipse-networks. c om><7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> <87ABC782-5999-460D-9DBF-8773C16C3344@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36D415@ENI-MAIL.eclipse-networks.com> You are entitled to your opinion and I?m entitled to mine. I?ve seen the best laid plans put together by people of good will - not work out as expected over and over in my life. I hope this doesn?t turn out to be one of those. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, July 18, 2014 6:57 PM To: Steven Ryerse Cc: John Curran; Kevin Blumberg; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 I can't help it if you choose to ignore the facts. Your concern has been repeatedly debunked by the AC, staff, and other members of the list. It simply isn't an accurate or valid concern. Anyone that can get a larger block now will still be able to get the same size block with the same effort if 2014-13 is implemented. All 2014-13 does is make it possible for people to get smaller blocks than were previously possible in some cases, enabling organizations that previously could not get any size block to now get some block. Owen On Jul 18, 2014, at 09:47 , Steven Ryerse > wrote: While I am concerned that my policy proposal would be affected, my larger concern is that this policy will make it harder for smaller organizations in practice to receive allocations at the low end of the scale right above a /24. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, July 17, 2014 5:27 AM To: Steven Ryerse Cc: John Curran; Kevin Blumberg; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 Member of the AC hat on (though not speaking on behalf of the AC): If this proposal gains traction and 2014-13 is adopted, the AC and the community can make the necessary adjustments to it in light of 2014-13 if 2014-13 is adopted. Changing 2014-13 so substantially at this time would only serve to delay its potential implementation without actually benefiting this proposal. If such a range is desired to go with this proposal, the necessary changes can be added to this proposal without significant difficulty. AC hat off -- Speaking only as myself and a member of the community at large: I fail to see the logic in establishing a "minimum range". A minimum is just that... A minimum. Anything larger than the minimum is not the minimum, so a minimum range is a minimum and some other numbers that happen to be larger than the minimum. Even if 2014-13 were somehow modified and we were able to work past the lexical cognitive dissonance inherent in the idea of a "minimum range", I don't see how this proposal would work without significant modification to deal with the issue of how a request is mapped to a particular "minimum" within the "minimum range" that applies by as yet unspecified criteria. Perhaps if you could clarify how you see this idea of a "minimum range" working and how it could actually be implemented or what it is you hope having such a thing would provide that the existing policy and/or 2014-13 does not provide, it would be helpful. Owen On Jul 13, 2014, at 10:39 , Steven Ryerse > wrote: Its more complicated than that. I?ve submitted the proposed policy change below to the AC. Obviously at this early stage I don?t know if the Community will accept this or not but 2014-13 complicates this proposal. That is part of the reason why I suggested changing 2014-13 to specify a range rather than a fixed allocation. I would be fine with having this proposal included with 2014-13 if the AC though that made sense. Otherwise it can remain separate. TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments 2. Proposal Originator a. name: Steven Ryerse b. email: SRyerse at eclipse-networks.com c. telephone: 770.656.1460 (c) 770.399.9099 (w) d. organization: Eclipse Networks Inc. 3. Date: 06-JUN-2014 4. Problem Statement: New and small organizations are having a difficult time receiving resource allocations from ARIN because of the economic, administrative and time burdens of making their way through ARIN's needs testing process. For small allocations, the burdens of needs testing may exceed the value of the resources, or may deter small, less well-funded organizations' ability to receive an allocation from ARIN. As ARIN was created to provide Internet resources to ALL organizations within its geographic territory, this disparity in the Policy Manual needs to be addressed. The problem can be remedied by removing needs testing for any organization that applies to receive the current minimum block size allocation. 5. Policy statement: "A Minimum IP allocation size(s) has been defined per Section 4 of the ARIN Number Resource Policy Manual. Regardless of any policy requirement(s) defined in any other active Section of the Policy Manual, all organizations may apply and shall automatically qualify for the current Minimum IP Block Allocation upon completing the normal administrative application process and fee requirements, and all organizations shall be eligible for such an allocation once every 12 months. Where this is in conflict with any other Section in the Policy Manual, this Section shall be controlling." 6. Comments: a. Timetable for implementation: Immediate b. Anything else: 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? From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, July 13, 2014 8:47 AM To: Kevin Blumberg Cc: Steven Ryerse; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 On Jul 12, 2014, at 10:02 AM, Kevin Blumberg > wrote: Steven, I?ve double checked with staff and this proposal will not make allocations or assignments larger than /24 more difficult than today. In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and larger prefixes, it isn?t limited to only a /24. Correct. An updated staff assessment is forthcoming which adds the sentence: "If implemented, staff would continue using these well established criteria and guidelines for initial requests larger than /24." FYI, /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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From gary.buhrmaster at gmail.com Fri Jul 18 21:40:52 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 19 Jul 2014 01:40:52 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36D415@ENI-MAIL.eclipse-networks.com> References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> <87ABC782-5999-460D-9DBF-8773C16C3344@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36D415@ENI-MAIL.eclipse-networks.com> Message-ID: On Fri, Jul 18, 2014 at 11:42 PM, Steven Ryerse wrote: > > You are entitled to your opinion and I?m entitled to mine. Absolutely, but you have been unable to articulate a compelling scenario as to how this will negatively impact the region and the members who request numbers. If you would share the specific example of how being able to get a /24 (whereas before they would qualify for nothing having too small of a justified need) will end up hurting the community, you need to share. We are not mind readers (well, at least I am not, I can not speak to any psychic abilities that others that participate on this list may claim to have). Thanks. From SRyerse at eclipse-networks.com Sat Jul 19 14:04:02 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sat, 19 Jul 2014 18:04:02 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.loc al><4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net><5B9E90747FA2974D91A 54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com><23F6889A-39AA-45B0-A C42-F1F8B4E47019@delong.com><5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI -MAIL.eclipse-networks.com><87ABC782-5999-460D-9DBF-8773C16C3344@delong.com ><5B9E90747FA2974D91A54FCFA1B8AD12015B36D415@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B36DC79@ENI-MAIL.eclipse-networks.com> I've said this before, but this proposal might help an Org that only needs a /24 but I think it will hurt an Org that needs a /20 or a /22 as the needs test that are applied will force them into qualifying for the /24 but not the /20 or /22 they legitimately need. Orgs that legitimately need a slightly larger allocation because of the gyrations they must go thru to try and justify a larger allocation, will end up not qualifying even though they have a legitimate need. The solution here is to completely remove the needs tests at the low end and not just on a /24. Proposal like 2014-13 are just dancing around the problem instead of trying to legitimately fix it. Small Organizations are very much under-represented in this Community and therefore their reasonable interests go under-represented. I do appreciate you asking Gary but I don't see the needs of small Organizations truly represented in this Community. 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: Gary Buhrmaster [mailto:gary.buhrmaster at gmail.com] Sent: Friday, July 18, 2014 9:41 PM To: Steven Ryerse Cc: Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2014-13 On Fri, Jul 18, 2014 at 11:42 PM, Steven Ryerse wrote: > > You are entitled to your opinion and I?m entitled to mine. Absolutely, but you have been unable to articulate a compelling scenario as to how this will negatively impact the region and the members who request numbers. If you would share the specific example of how being able to get a /24 (whereas before they would qualify for nothing having too small of a justified need) will end up hurting the community, you need to share. We are not mind readers (well, at least I am not, I can not speak to any psychic abilities that others that participate on this list may claim to have). Thanks. From rbf+arin-ppml at panix.com Sat Jul 19 15:52:18 2014 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sat, 19 Jul 2014 14:52:18 -0500 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <87ABC782-5999-460D-9DBF-8773C16C3344@delong.com> References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> <87ABC782-5999-460D-9DBF-8773C16C3344@delong.com> Message-ID: <20140719195217.GA22940@panix.com> On Fri, Jul 18, 2014 at 03:57:09PM -0700, Owen DeLong wrote: > I can't help it if you choose to ignore the facts. Your concern has > been repeatedly debunked by the AC, staff, and other members of the > list. It simply isn't an accurate or valid concern. > > Anyone that can get a larger block now will still be able to get the > same size block with the same effort if 2014-13 is implemented. > > All 2014-13 does is make it possible for people to get smaller blocks > than were previously possible in some cases, enabling organizations > that previously could not get any size block to now get some block. I think you're ignoring human nature, and the reality that while poliy is absolute, actual implementation in practice is not. >From a pure policy perspective, you (and others who have made the same claim) are correct. Under policy today (in the general case), if you can justify for a /22, you can get one; if you can justify a /24 but not a /22, you get nothing. Under 2014-13, if you can justify a /22, you can get one; if you can justify a /24 but not a /22, you can get a /24. So no one loses anything, and those that can justify a /24 (but not a /22) can get space from ARIN when previously they couldn't. However, let's consider a provider whose justification is right on the border between a /23 and a /22. Depending on interpretation, it could go either way. If you gave the justification to 20 qualified analysts, 10 +/- 2 of then would say "a /23 is justified"; 10 +/- 2 of them would say "a /22 is justified". In that case, without 2014-13, the ARIN analyst whose first reaction to the request is "/23" is likely read it a few more times and then convince himself a /22 is justified, to avoid having to completely deny the request. In a world with 2014-13, the ARIN analyst whose first reaction to the request is "/23" is likely to approve only the /23. The requestor who clearly justifies a /22 is not going to be harmed (or helped) by this proposal. The requestor who just barely justifies a /24 is clearly going to be helped by this proposal. But the requestors on the edge might be harmed. Should there be ambiguous cases that give rise to those sort of risk? Perhaps not, but the world is messy, and there will be. Should ARIN be resolving corner cases to the low side when the consequences are minor (requester gets space, just less of it) and to the high side when the consequences (of resolving to the low side) are more serious (requestor gets no space)? Perhaps not. But if the bias is to work with customers to get space as long as a way to do the allocation within policy can be found, it's likely that some of that will happen. Are these corner cases reason to reject 2014-13. I don't think so. But I also don't think we should pretend they do not exist. -- Brett From jcurran at arin.net Sat Jul 19 16:12:36 2014 From: jcurran at arin.net (John Curran) Date: Sat, 19 Jul 2014 20:12:36 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <20140719195217.GA22940@panix.com> References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.local> <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com> <23F6889A-39AA-45B0-AC42-F1F8B4E47019@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI-MAIL.eclipse-networks.com> <87ABC782-5999-460D-9DBF-8773C16C3344@delong.com> <20140719195217.GA22940@panix.com> Message-ID: On Jul 19, 2014, at 3:52 PM, Brett Frankenberger wrote: > However, let's consider a provider whose justification is right on the > border between a /23 and a /22. Depending on interpretation, it could > go either way. If you gave the justification to 20 qualified analysts, > 10 +/- 2 of then would say "a /23 is justified"; 10 +/- 2 of them would > say "a /22 is justified". Brett - Actually, the analysts first work to determine the prior run rate of address utilization so two analysts get the same numerical result if given the same supporting information by the requesters. This has been confirmed many times, when requests that are appealed get calculated again by our COO and myself, and the calculation is independent of request size. Once we have the run rate, it is extrapolated out 3 months as required by NRPM 4.2.2 allocation policy to see if request is warranted. It is possible that parties who can now receive a /24 will obtain a smaller block than they would if they otherwise waited, but that result obviously that is a choice on the part of the requester. Thanks! /John John Curran President and CEO ARIN From owen at delong.com Sat Jul 19 18:42:05 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Jul 2014 15:42:05 -0700 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36DC79@ENI-MAIL.eclipse-networks.com> References: <7E7773B523E82C478734E793E58F69E78D7E9779@SBS2011.thewireinc.loc al><4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net><5B9E90747FA2974D91A 54FCFA1B8AD12015B36409B@ENI-MAIL.eclipse-networks.com><23F6889A-39AA-45B0-A C42-F1F8B4E47019@delong.com><5B9E90747FA2974D91A54FCFA1B8AD12015B36C63C@ENI -MAIL.eclipse-networks.com><87ABC782-5999-460D-9DBF-8773C16C3344@delong.com ><5B9E90747FA2974D91A54FCFA1B8AD12015B36D415@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36DC79@ENI-MAIL.eclipse-networks.com> Message-ID: <194CCA71-3F40-4831-A906-331ABB34E3BD@delong.com> On Jul 19, 2014, at 11:04 , Steven Ryerse wrote: > I've said this before, but this proposal might help an Org that only needs a /24 but I think it will hurt an Org that needs a /20 or a /22 as the needs test that are applied will force them into qualifying for the /24 but not the /20 or /22 they legitimately need. Orgs that legitimately need a slightly larger allocation because of the gyrations they must go thru to try and justify a larger allocation, will end up not qualifying even though they have a legitimate need. The solution here is to completely remove the needs tests at the low end and not just on a /24. Proposal like 2014-13 are just dancing around the problem instead of trying to legitimately fix it. How do you expect this to happen? If they don't pass the needs test for a /20 under this policy, then they wouldn't pass the needs test for a /20 today. The only difference would be: Under this policy, they might get something smaller that they do pass the test for. Today, they get nothing. This policy does not change the needs test. So how do you come to the conclusion that it will somehow do so? Do you have any factual basis to believe otherwise? If so, can you please enumerate what that is? > Small Organizations are very much under-represented in this Community and therefore their reasonable interests go under-represented. I do appreciate you asking Gary but I don't see the needs of small Organizations truly represented in this Community. I have to disagree with you here. While larger organizations are over-represented as a percentage of organizations served by ARIN, they still are not the majority of those participating in the policy process. They are still pretty well outnumbered by smaller organizations. Owen From rbf+arin-ppml at panix.com Sun Jul 20 14:02:14 2014 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sun, 20 Jul 2014 13:02:14 -0500 Subject: [arin-ppml] ARIN 2014-13 Message-ID: <20140720180213.GA22120@panix.com> On Sat, Jul 19, 2014 at 08:12:36PM +0000, John Curran wrote: > On Jul 19, 2014, at 3:52 PM, Brett Frankenberger wrote: > > > However, let's consider a provider whose justification is right on the > > border between a /23 and a /22. Depending on interpretation, it could > > go either way. If you gave the justification to 20 qualified analysts, > > 10 +/- 2 of then would say "a /23 is justified"; 10 +/- 2 of them would > > say "a /22 is justified". > > Actually, the analysts first work to determine the prior run rate of > address utilization so two analysts get the same numerical result if > given the same supporting information by the requesters. This has > been confirmed many times, when requests that are appealed get > calculated again by our COO and myself, and the calculation is > independent of request size. Once we have the run rate, it is > extrapolated out 3 months as required by NRPM 4.2.2 allocation policy > to see if request is warranted. You're decribing the 4.2.4 case (ISP Additional Requests), where the appropriate size of the allocation can be objectively determined by calculating run rate looking backwards. I agree that those calculations would not be impacted by 2014-13. But even if ARIN's practice is to apply that rule exclusivly (and not also consider justification based on, for example, an increasing rate of consumption going forward (with appropriate evidence)) in the cases of ISP additional requests, that's not the only category of request ... ISP initial allocations and End User initial and additional assignment requests would not be able to be analyzed using such completely objective criteria. > It is possible that parties who can now receive a /24 will obtain a > smaller block than they would if they otherwise waited, but that > result obviously that is a choice on the part of the requester. Agreed. -- Brett From gary.buhrmaster at gmail.com Sun Jul 20 15:02:40 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 20 Jul 2014 19:02:40 +0000 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <20140720180213.GA22120@panix.com> References: <20140720180213.GA22120@panix.com> Message-ID: On Sun, Jul 20, 2014 at 6:02 PM, Brett Frankenberger wrote: > ISP initial allocations and End User initial and additional assignment > requests would not be able to be analyzed using such completely > objective criteria. While I expect humans will continue to be fallible, over the decades from when assignments may have had some element of what "feels right", the NRPM has become sufficiently prescriptive that I would image that almost all of the subjectivity has been sucked out of the process. That is part of the process of becoming a mature organization and creating formal protocols. From mpetach at netflight.com Mon Jul 21 14:11:33 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 21 Jul 2014 11:11:33 -0700 Subject: [arin-ppml] ARIN 2014-13 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015B36DC79@ENI-MAIL.eclipse-networks.com> References: <4F8EDEB2-F9A9-46E6-8571-14F40CF06F21@corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12015B36D415@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015B36DC79@ENI-MAIL.eclipse-networks.com> Message-ID: On Sat, Jul 19, 2014 at 11:04 AM, Steven Ryerse < SRyerse at eclipse-networks.com> wrote: > I've said this before, but this proposal might help an Org that only needs > a /24 but I think it will hurt an Org that needs a /20 or a /22 as the > needs test that are applied will force them into qualifying for the /24 but > not the /20 or /22 they legitimately need. Steve, I count four uses of the word "need" in that sentence; I suspect part of the problem here is that you're using "need" in two different ways, while the rest of the list is thinking of just one use of the word "need". You say "I think it will hurt an Org that needs a /20 or a /22" --ok, we've established their org has a requirement for a certain size block--to keep it straight, let's say their use case requires a /22. You than continue by saying "as the needs test that are applied will force them into qualifying for the /24" --here's where the confusion starts; you seem to be saying the needs test will evaluate their stated requirement, and determine only a /24 is actually required for their use case. That is, the evaluation of the requirements by the Org are different than the evaluation of the requirements by ARIN. You then conclude by saying "but not the /20 or /22 they legitimately need." --here, the use of "legitimately need" seems to be designed to try to frame it in opposition to the "need" of "needs test" used in the previous clause, and seems to focus on reinforcing the idea that the Org has evaluated their requirements differently from ARIN. As humans, we sometimes have a tendency to think we know best; that when we come up with an idea, it's somehow the best possible idea, the best possible way to approach a situation. And yet, it's not uncommon to find that others have in the past come up with similar ideas, with possibly slightly different solutions, some of which might actually be more efficient when viewed objectively. Part of the drive here from the community is to help guide organizations into using the most efficient solutions we have available to us as a whole. In the past, people thought that web hosting meant you needed a different IP address for every virtual host you ran; I know I configured my early web farms that way. But then use of the Host: header became more widespread, and we slowly learned we didn't need to allocate huge swaths of IP space to webservers just to handle multiple virtual hosts. We've codified that knowledge into the allocation guidelines, so that future Orgs that show up asking for a /22 so that they can run multiple virtual hosts on their one server can be gently steered towards how to configure their servers in a more efficient manner, using less of a scarce resource. This doesn't mean the Org coming with the request for a /22 didn't feel they had a completely legitimate need, that their installation *required* the full block of address space. In their eyes, that was what was needed, and anyone saying otherwise was trying to stop them from doing business. But from an outside perspective, the Org was attempting to make use of a less efficient way to run their web farm, and pushing back on the request with a nudge towards a more efficient means of serving virtual hosts off a single IP address would be the only reasonable response; it would be unethical for the community to not help guide that Org towards a more efficient mode of operation. I've never seen an organization get turned down for IP space that could clearly document the basis for their IP address requirements. I *have* been turned down myself, in the past, when my thoughts on what number resources were required did not follow the best practices for the industry; and I took the gentle rejection and recommendation to heart, learned a better way to do virtual hosting, and came back with an updated request that better matched what the industry best practices actually required. What we're doing here is not trying to stifle new businesses; what we want to do is make sure that new businesses understand that there are efficient ways to use resources, and inefficient ways to use resources, and as a community, we're trying to steer those businesses towards using the resources in the most efficient way we've discovered so far. So, getting back to your original statement, with its somewhat confusing 4 uses of the word "needs", I think a clearer statement of your concern would have been: I've said this before, but this proposal might help an Org that only optimally requires a /24 but I think it will hurt an Org that thinks their application will require a /20 or a /22, but the needs test that are applied will recommend a more efficient solution that only requires a /24, not the /20 or /22 they initially felt would be needed. If the organization truly has a 'legitimate need', in that they are already working towards the most efficient solution the industry is aware of, and have documented their application of that best practice, I don't think these proposals will in any way jeopardize their ability to get those resources. > Orgs that legitimately need a slightly larger allocation because of the > gyrations they must go thru to try and justify a larger allocation, will > end up not qualifying even though they have a legitimate need. The > solution here is to completely remove the needs tests at the low end and > not just on a /24. Proposal like 2014-13 are just dancing around the > problem instead of trying to legitimately fix it. > Again, I suspect the use of the term "legitimately need" here is slightly mis-used. You don't "legitimately need" a larger allocation just because you feel there's gyrations you have to go through. The community is helping guide you to a more efficient way of using number resources; those 'gyrations' are efforts to avoid learning the more efficient ways to use the resources. It's rather like burning coal for electricity. Yes, it's quick and easy and people wonder why they can't just do that, rather than developing more sustainable alternatives like solar, hydro, or wind power; but the fact is, as a community, we can't allow the ongoing destruction of limited community resources (limited supply of coal in the ground, limited supply of fresh, unpolluted air to breathe) simply because it's easier for you to do business that way. Water is in a similar position; for centuries, everyone took water for granted; now that fresh water is running out, we're suddenly faced with the same challenges as the ARIN community. We're having to push back on people and companies that have been used to using it inefficiently for years, and trying to explain that there's just not enough left--you can't continue doing business as usual, you have to learn more efficient ways of using the resource if we're all going to survive. Removing all "needs" testing sounds great in the short term; but I suspect those who cry out most loudly for removing the needs requirements would soon be crying out for subsidies or other interventions when the well runs dry, and the only way to get more is to buy from those that still have some. Much better to learn how to be efficient now while you still can, than count on being profligate until suddenly there's nothing left in the well to draw from. > > Small Organizations are very much under-represented in this Community and > therefore their reasonable interests go under-represented. I do appreciate > you asking Gary but I don't see the needs of small Organizations truly > represented in this Community. > Fair enough; I suspect, however, as there's no particular barrier to entry for those smaller organizations to participate in this community, that most of them are sufficiently well served currently to not feel a need to speak out. I know when I'm happy, I tend to not feel the need to jump up and tell everyone I'm happy with the way the world is; but when I'm unhappy, I'm much more inclined to speak out. I *suppose* ARIN could add a one-line question to the renewal process for annual resource fees-- "Please indicate how well represented you feel your interests are in the ARIN community, on a scale of 1 to 10, 1 being 'I feel my interests are completely unrepresented', and 10 being 'John Curran carries out my every whim and waking desire.'" That would give us more concrete insight into whether small Organizations feel their interests are not well represented. But I'll have to leave that to John to decide whether gathering that level of data is practical or not. Thanks! Matt > > 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: Gary Buhrmaster [mailto:gary.buhrmaster at gmail.com] > Sent: Friday, July 18, 2014 9:41 PM > To: Steven Ryerse > Cc: Owen DeLong; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN 2014-13 > > On Fri, Jul 18, 2014 at 11:42 PM, Steven Ryerse < > SRyerse at eclipse-networks.com> wrote: > > > > You are entitled to your opinion and I?m entitled to mine. > > Absolutely, but you have been unable to articulate a compelling scenario > as to how this will negatively impact the region and the members who > request numbers. If you would share the specific example of how being able > to get a /24 (whereas before they would qualify for nothing having too > small of a justified need) will end up hurting the community, you need to > share. We are not mind readers (well, at least I am not, I can not speak > to any psychic abilities that others that participate on this list may > claim to have). Thanks. > _______________________________________________ > 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 Tue Jul 22 15:21:20 2014 From: info at arin.net (ARIN) Date: Tue, 22 Jul 2014 15:21:20 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 Message-ID: <53CEB9B0.9030804@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 17 July 2014. The AC recommended the following to the ARIN Board for adoption: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations Recommended Draft Policy ARIN-2414-12: Anti-hijack Policy Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 Having found the following draft policy to be fully developed and meeting ARIN's Principles of Internet Number Resource Policy, the AC recommended it for adoption: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements The AC accepted the following Proposal as a Draft Policy: ARIN-prop-210 Simplifying Minimum Allocations and Assignments The AC is continuing to work on the following: Draft Policy ARIN-2014-1: Out of Region Use Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate 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 michael at linuxmagic.com Tue Jul 22 15:46:59 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 22 Jul 2014 12:46:59 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 In-Reply-To: <53CEB9B0.9030804@arin.net> References: <53CEB9B0.9030804@arin.net> Message-ID: <53CEBFB3.2090701@linuxmagic.com> On 14-07-22 12:21 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) met on 17 July 2014. > > The AC recommended the following to the ARIN Board for adoption: > > Allocation/Assignment Units to /24 Nice to see.. hopefully it doesn't add too much to ARIN workloads, but we know that many of the little voices out there will thank you. > Draft Policy ARIN-2014-1: Out of Region Use I still think more conversation is needed on this one, there are a lot of implications, positive and negative. > Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] +1, ARIN has enough troubles dealing with issues that are of a higher priority, so let's work on dealing with more important issues. A shame that there isn't a replacement pointing to a new responsible entity of course. > Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers This one, while good in intent, is still confusing.. (eg the language on the changes concerns /16's which isn't really a small IPv4 Transfer) > Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers +1, all logical, can't really see how that can be abused. > Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update Small concern.. 2. the organization must show immediate use (within 30 days) of 25% of the allocation; Is 30 days too aggressive? Upstream provider issues, unexpected technical issues? > Draft Policy ARIN-2014-17: Change Utilization Requirements from > last-allocation to total-aggregate This one I will be commenting more on, in response to Owen's comments, regarding language surrounding supporting other language elsewhere concerning 'rwhois'. General concept isn't bad, but adding language will ensure more professional and proscribed usage of the remaining IPv4 space. -- "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 owen at delong.com Tue Jul 22 16:20:01 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Jul 2014 13:20:01 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 In-Reply-To: <53CEBFB3.2090701@linuxmagic.com> References: <53CEB9B0.9030804@arin.net> <53CEBFB3.2090701@linuxmagic.com> Message-ID: <7D79933D-D639-430C-9AFD-E0841D71B97B@delong.com> Michael, your quoting makes it look as if you are responding to us recommending 2014-1 et. al to the board. That's not what happened... On Jul 22, 2014, at 12:46 , Michael Peddemors wrote: > On 14-07-22 12:21 PM, ARIN wrote: >> In accordance with the ARIN Policy Development Process (PDP), the ARIN >> Advisory Council (AC) met on 17 July 2014. >> >> The AC recommended the following to the ARIN Board for adoption: >> >> Allocation/Assignment Units to /24 > > Nice to see.. hopefully it doesn't add too much to ARIN workloads, but we know that many of the little voices out there will thank you. > You left out an intervening line from the original message that is important: "The AC is continuing to work on the following:" That means that these proposals are still under discussion and more conversation is exactly what will continue to happen with them. Hope that clarifies what is going on. > >> Draft Policy ARIN-2014-1: Out of Region Use > > I still think more conversation is needed on this one, there are a lot of implications, positive and negative. > >> Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] > > +1, ARIN has enough troubles dealing with issues that are of a higher priority, so let's work on dealing with more important issues. > A shame that there isn't a replacement pointing to a new responsible entity of course. > >> Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers > > This one, while good in intent, is still confusing.. (eg the language on the changes concerns /16's which isn't really a small IPv4 Transfer) > > >> Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers > > +1, all logical, can't really see how that can be abused. > >> Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update > > Small concern.. > 2. the organization must show immediate use (within 30 days) of 25% of the allocation; > > Is 30 days too aggressive? Upstream provider issues, unexpected technical issues? > > >> Draft Policy ARIN-2014-17: Change Utilization Requirements from >> last-allocation to total-aggregate > > This one I will be commenting more on, in response to Owen's comments, regarding language surrounding supporting other language elsewhere concerning 'rwhois'. General concept isn't bad, but adding language will ensure more professional and proscribed usage of the remaining IPv4 space. > > > > -- > "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. > _______________________________________________ > 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 michael at linuxmagic.com Tue Jul 22 17:19:21 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 22 Jul 2014 14:19:21 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 In-Reply-To: <7D79933D-D639-430C-9AFD-E0841D71B97B@delong.com> References: <53CEB9B0.9030804@arin.net> <53CEBFB3.2090701@linuxmagic.com> <7D79933D-D639-430C-9AFD-E0841D71B97B@delong.com> Message-ID: <53CED559.3020300@linuxmagic.com> On 14-07-22 01:20 PM, Owen DeLong wrote: > Michael, your quoting makes it look as if you are responding to us > recommending 2014-1 et. al to the board. > > That's not what happened... > > > On Jul 22, 2014, at 12:46 , Michael Peddemors > wrote: > >> On 14-07-22 12:21 PM, ARIN wrote: >>> In accordance with the ARIN Policy Development Process (PDP), the ARIN >>> Advisory Council (AC) met on 17 July 2014. >>> >>> The AC recommended the following to the ARIN Board for adoption: >>> >>> Allocation/Assignment Units to /24 >> >> Nice to see.. hopefully it doesn't add too much to ARIN workloads, but >> we know that many of the little voices out there will thank you. >> > > You left out an intervening line from the original message that is > important: > > "The AC is continuing to work on the following:" > > That means that these proposals are still under discussion and more > conversation is exactly what will continue to happen with them. > Apologies, sorry I understood that, I guess for other readers it wasn't obvious, I was just trying to start the .. 'continuing to work on the following' :) -- "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 scottleibrand at gmail.com Tue Jul 22 18:59:46 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Jul 2014 15:59:46 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 In-Reply-To: <53CEBFB3.2090701@linuxmagic.com> References: <53CEB9B0.9030804@arin.net> <53CEBFB3.2090701@linuxmagic.com> Message-ID: On Tue, Jul 22, 2014 at 12:46 PM, Michael Peddemors wrote: The AC is continuing to work on the following: > Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers >> > > +1, all logical, can't really see how that can be abused. The main concern now is the impact of Inter-RIR ASN Transfers on the RPKI system. Geoff brought up the issue at the NANOG PPC in Bellevue, and the subsequent staff assessment highlighted the fact that ARIN would need to do additional RPKI development to make Inter-RIR ASN transfers work with RPKI. Therefore, most of the AC felt (and convinced me) that we shouldn't recommend ARIN-2014-15 for adoption after Baltimore, but rather should leave it as a Draft Policy and discuss the RPKI issues there. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Jul 23 10:58:02 2014 From: info at arin.net (ARIN) Date: Wed, 23 Jul 2014 10:58:02 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments Message-ID: <53CFCD7A.8060809@arin.net> On 17 July 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-210 Simplifying Minimum Allocations and Assignments" as a Draft Policy. Draft Policy ARIN-2014-18 is below and can be found at: https://www.arin.net/policy/proposals/2014_18.html You are encouraged to discuss the merits and your concerns of Draft Policy 2014-18 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-2014-18 Simplifying Minimum Allocations and Assignments Date: 23 July 2014 Problem Statement: New and small organizations are having a difficult time receiving resource allocations from ARIN because of the economic, administrative and time burdens of making their way through ARIN?s needs testing process. For small allocations, the burdens of needs testing may exceed the value of the resources, or may deter small, less well-funded organizations? ability to receive an allocation from ARIN. As ARIN was created to provide Internet resources to ALL organizations within its geographic territory, this disparity in the Policy Manual needs to be addressed. The problem can be remedied by removing needs testing for any organization that applies to receive the current minimum block size allocation. Policy statement: Therefore I propose the following addition to the Policy Manual (possibly as 4.2.1.7): ?A Minimum IP allocation size(s) has been defined per Section 4 of the ARIN Number Resource Policy Manual. Regardless of any policy requirement(s) defined in any other active Section of the Policy Manual, all organizations may apply and shall automatically qualify for the current Minimum IP Block Allocation upon completing the normal administrative application process and fee requirements, and all organizations shall be eligible for such an allocation once every 12 months. Where this is in conflict with any other Section in the Policy Manual, this Section shall be controlling.? Comments: a. Timetable for implementation: b. Anything else: From info at arin.net Wed Jul 23 11:27:07 2014 From: info at arin.net (ARIN) Date: Wed, 23 Jul 2014 11:27:07 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements Message-ID: <53CFD44B.8040309@arin.net> Recommended Draft Policy ARIN-2014-9 Resolve Conflict Between RSA and 8.2 Utilization Requirements On 17 July 2014 the ARIN Advisory Council (AC) recommended ARIN-2014-9 for adoption, making it a Recommended Draft Policy. ARIN-2014-9 is below and can be found at: https://www.arin.net/policy/proposals/2014_9.html You are encouraged to discuss Draft Policy 2014-9 on the PPML prior to the upcoming ARIN Public Policy Consulation at NANOG 62 and ARIN 34 in Baltimore, Maryland in October. Both the discussion on the list and at the meetings will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2014-9 Resolve Conflict Between RSA and 8.2 Utilization Requirements Date: 23 July 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: "This proposal enables fair and impartial number resource administration by eliminating conflicting language in the NRPM with the RSA. This proposal is technically sound. The NRPM should not contain language that conflicts with the RSA. This proposal is supported by the community. This proposal reflects current practice." Problem Statement: 8.2 transfer policy has utilization requirements at the time of the review of the transfer request. The RSA section 6 expressly forbids ARIN from de-registering blocks (in whole or in part) due to under-utilization or no-justification during transfer requests. This is a direct conflict. Policy statement: Remove the words "aggregate" and "reclaim" from 8.2, so it reads: "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: a.Timetable for implementation: Immediate b.Anything else: ##### Recommended Draft Policy ARIN-2014-9 Resolve Conflict Between RSA and 8.2 Utilization Requirements Staff Assessment Date of Assessment: 01 July 2014 1. Summary (Staff Understanding) This proposal would revise NRPM 8.2 ?Mergers and Acquisitions? by removing aggregation and reclamation of resources as a method to restore compliance with current policy. 2. Comments A. ARIN Staff Comments Removing the aggregation terminology from the policy is appropriate given the retirement of the aggregation policy language elsewhere in the NRPM. Removing the reclamation terminology from the policy may encourage more people to complete 8.2 transfers because the reclamation aspect is no longer part of the policy. Staff frequently sees cases where organizations are transferring resources that are not being utilized and lack a clear plan to utilize or transfer them in the future. This is a dilemma that exists today and will continue to exist with the revised policy. Staff will encourage such organizations to make use of their resources, work with staff to voluntarily return unused resources to ARIN, or transfer them to parties who need them. The problem statement does not specify which version and date of the RSA [section 6]. This is a reconciliation issue between policy and RSA and therefore staff interprets this proposal as pertaining to current RSA version 11.0 (2012-04-20) [section 6]. B. ARIN General Counsel - Legal Assessment This proposal does not appear to pose any material legal issues. 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-9 Resolve Conflict Between RSA and 8.2 Utilization Requirements Revised: 16 May 2014 Problem Statement: 8.2 transfer policy has utilization requirements at the time of the review of the transfer request. The RSA section 6 expressly forbids ARIN from de-registering blocks (in whole or in part) due to under-utilization or no-justification during transfer requests. This is a direct conflict. Policy statement: Remove the words "aggregate" and "reclaim" from 8.2, so it reads: "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." From gary.buhrmaster at gmail.com Wed Jul 23 12:58:54 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 23 Jul 2014 16:58:54 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: <53CFCD7A.8060809@arin.net> References: <53CFCD7A.8060809@arin.net> Message-ID: On Wed, Jul 23, 2014 at 2:58 PM, ARIN wrote: > On 17 July 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-210 > Simplifying Minimum Allocations and Assignments" as a Draft Policy. > > Draft Policy ARIN-2014-18 is below and can be found at: > https://www.arin.net/policy/proposals/2014_18.html Opposed as written. I believe that continued needs testing is an important criteria for receiving resources, and this proposal would eliminate justified needs testing. As to the costs of doing business, well, while I can understand the those seeking resources may not have properly planned for the costs of their start up and/or expansion, that is a failure of the requesting organization(s) leaders and their staff, and requesting relief from ARIN policy because of that failure is not an appropriate response. If it gets too hot in the kitchen, do not be a cook. From farmer at umn.edu Wed Jul 23 13:13:31 2014 From: farmer at umn.edu (David Farmer) Date: Wed, 23 Jul 2014 12:13:31 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <53CFD44B.8040309@arin.net> References: <53CFD44B.8040309@arin.net> Message-ID: <53CFED3B.7090604@umn.edu> On 7/23/14, 10:27 , ARIN wrote: ... > Recommended Draft Policy ARIN-2014-9 > Resolve Conflict Between RSA and 8.2 Utilization Requirements > > Date: 23 July 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > "This proposal enables fair and impartial number resource administration > by eliminating conflicting language in the NRPM with the RSA. This > proposal is technically sound. The NRPM should not contain language that > conflicts with the RSA. This proposal is supported by the community. > This proposal reflects current practice." > > Problem Statement: > > 8.2 transfer policy has utilization requirements at the time of the > review of the transfer request. > > The RSA section 6 expressly forbids ARIN from de-registering blocks (in > whole or in part) due to under-utilization or no-justification during > transfer requests. > > This is a direct conflict. > > Policy statement: > > Remove the words "aggregate" and "reclaim" from 8.2, so it reads: > > "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." While I support the original version of this policy that completely removed this clause and the requirement for a resource review as part of an 8.2 transfer. I also support this version that removes the words "aggregate" and "reclaim" from 8.2. I believe it is absolutely necessary to resolve the conflict described in the problem statement and this policy text accomplishes that goal. While I support eliminating the requirement for a resource review as part of an 8.2 transfer, I feel that goes beyond what is minimally necessary to resolve the conflict described in the problem statement. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From ikiris at gmail.com Wed Jul 23 13:17:43 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 23 Jul 2014 12:17:43 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: <53CFCD7A.8060809@arin.net> References: <53CFCD7A.8060809@arin.net> Message-ID: Opposed, as I do not see the need to justify 200 addresses as enough of a burden to outweigh the benefits of not giving out /24s like candy to those who cannot when coupled with the likely to be implemented minimum /24 size allocation to an ORG. The laws of physics cause this to be needed, due to current technology used to preform the basic functions of the internet. This would not be good stewardship of the resource as this is a remarkably low barrier to entry considering the ramifications. -Blake On Wed, Jul 23, 2014 at 9:58 AM, ARIN wrote: > On 17 July 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-210 > Simplifying Minimum Allocations and Assignments" as a Draft Policy. > > Draft Policy ARIN-2014-18 is below and can be found at: > https://www.arin.net/policy/proposals/2014_18.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2014-18 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-2014-18 > Simplifying Minimum Allocations and Assignments > > Date: 23 July 2014 > > Problem Statement: > > New and small organizations are having a difficult time receiving resource > allocations from ARIN because of the economic, administrative and time > burdens of making their way through ARIN?s needs testing process. For small > allocations, the burdens of needs testing may exceed the value of the > resources, or may deter small, less well-funded organizations? ability to > receive an allocation from ARIN. As ARIN was created to provide Internet > resources to ALL organizations within its geographic territory, this > disparity in the Policy Manual needs to be addressed. The problem can be > remedied by removing needs testing for any organization that applies to > receive the current minimum block size allocation. > > Policy statement: > > Therefore I propose the following addition to the Policy Manual (possibly as > 4.2.1.7): > ?A Minimum IP allocation size(s) has been defined per Section 4 of the ARIN > Number Resource Policy Manual. Regardless of any policy requirement(s) > defined in any other active Section of the Policy Manual, all organizations > may apply and shall automatically qualify for the current Minimum IP Block > Allocation upon completing the normal administrative application process and > fee requirements, and all organizations shall be eligible for such an > allocation once every 12 months. Where this is in conflict with any other > Section in the Policy Manual, this Section shall be controlling.? > > Comments: > a. Timetable for implementation: > b. Anything else: > _______________________________________________ > 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 mike at iptrading.com Wed Jul 23 13:44:39 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 23 Jul 2014 13:44:39 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: References: <53CFCD7A.8060809@arin.net> Message-ID: <5670932556CD48E09C1A211A911330A9@MPC> I support the proposal. How else are we going to get rid of the more than 1,000 /24s left as the dregs of decades of allocations? It will take a long time to dole out one /24 every three months to each needy applicant, do we want to extend this near-exhaust environment? -----Original Message----- From: Blake Dunlap Sent: Wednesday, July 23, 2014 1:17 PM To: ARIN Cc: arin-ppml at arin.net List Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments Opposed, as I do not see the need to justify 200 addresses as enough of a burden to outweigh the benefits of not giving out /24s like candy to those who cannot when coupled with the likely to be implemented minimum /24 size allocation to an ORG. The laws of physics cause this to be needed, due to current technology used to preform the basic functions of the internet. This would not be good stewardship of the resource as this is a remarkably low barrier to entry considering the ramifications. -Blake On Wed, Jul 23, 2014 at 9:58 AM, ARIN wrote: > On 17 July 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-210 > Simplifying Minimum Allocations and Assignments" as a Draft Policy. > > Draft Policy ARIN-2014-18 is below and can be found at: > https://www.arin.net/policy/proposals/2014_18.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2014-18 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-2014-18 > Simplifying Minimum Allocations and Assignments > > Date: 23 July 2014 > > Problem Statement: > > New and small organizations are having a difficult time receiving resource > allocations from ARIN because of the economic, administrative and time > burdens of making their way through ARIN?s needs testing process. For > small > allocations, the burdens of needs testing may exceed the value of the > resources, or may deter small, less well-funded organizations? ability to > receive an allocation from ARIN. As ARIN was created to provide Internet > resources to ALL organizations within its geographic territory, this > disparity in the Policy Manual needs to be addressed. The problem can be > remedied by removing needs testing for any organization that applies to > receive the current minimum block size allocation. > > Policy statement: > > Therefore I propose the following addition to the Policy Manual (possibly > as > 4.2.1.7): > ?A Minimum IP allocation size(s) has been defined per Section 4 of the > ARIN > Number Resource Policy Manual. Regardless of any policy requirement(s) > defined in any other active Section of the Policy Manual, all > organizations > may apply and shall automatically qualify for the current Minimum IP Block > Allocation upon completing the normal administrative application process > and > fee requirements, and all organizations shall be eligible for such an > allocation once every 12 months. Where this is in conflict with any other > Section in the Policy Manual, this Section shall be controlling.? > > Comments: > a. Timetable for implementation: > b. Anything else: > _______________________________________________ > 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 scottleibrand at gmail.com Wed Jul 23 13:54:14 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Jul 2014 10:54:14 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 In-Reply-To: References: <53CEB9B0.9030804@arin.net> <53CEBFB3.2090701@linuxmagic.com> Message-ID: On Tue, Jul 22, 2014 at 3:59 PM, Scott Leibrand wrote: > On Tue, Jul 22, 2014 at 12:46 PM, Michael Peddemors < > michael at linuxmagic.com> wrote: > > The AC is continuing to work on the following: > > >> Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers >>> >> >> +1, all logical, can't really see how that can be abused. >> > > The main concern now is the impact of Inter-RIR ASN Transfers on the RPKI > system. Geoff brought up the issue at the NANOG PPC in Bellevue, > To respond to a private query, Geoff's comments can be reviewed at https://www.arin.net/participate/meetings/reports/ppc_nanog61/ppc_transcript.html#anchor_14 -Scott > and the subsequent staff assessment highlighted the fact that ARIN would > need to do additional RPKI development to make Inter-RIR ASN transfers work > with RPKI. Therefore, most of the AC felt (and convinced me) that we > shouldn't recommend ARIN-2014-15 for adoption after Baltimore, but rather > should leave it as a Draft Policy and discuss the RPKI issues there. > > -Scott > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Wed Jul 23 14:10:07 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 23 Jul 2014 18:10:07 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: <5670932556CD48E09C1A211A911330A9@MPC> References: <53CFCD7A.8060809@arin.net> <5670932556CD48E09C1A211A911330A9@MPC> Message-ID: On Wed, Jul 23, 2014 at 5:44 PM, Mike Burns wrote: > ..... How else are we going to get rid of the more than > 1,000 /24s left as the dregs of decades of allocations? Well, you could always reintroduce the proposal that everyone who commented (on that proposal proposal) would get a /24 given to them. It would likely increase PPML participation for a short period. From mike at iptrading.com Wed Jul 23 15:41:23 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 23 Jul 2014 15:41:23 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 References: <53CEB9B0.9030804@arin.net> <53CEBFB3.2090701@linuxmagic.com> Message-ID: <2005BBF2470E4243A4286D61C22711B3@ncsscfoipoxes4> I support further discussion of the RPKI issue. I don't think it will be difficult to overcome the issues raised by Mr. Huston, but since demand for Inter-RIR ASN transfers is low, there is little harm in waiting to get it right. I know there were some procedural wrinkles involved in early Inter-RIR address transfers and we may be able to anticipate and work around these kinds of things through further discussion. ----- Original Message ----- From: Scott Leibrand To: Michael Peddemors Cc: ARIN-PPML List Sent: Wednesday, July 23, 2014 1:54 PM Subject: Re: [arin-ppml] Advisory Council Meeting Results - July 2014 On Tue, Jul 22, 2014 at 3:59 PM, Scott Leibrand wrote: On Tue, Jul 22, 2014 at 12:46 PM, Michael Peddemors wrote: The AC is continuing to work on the following: Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers +1, all logical, can't really see how that can be abused. The main concern now is the impact of Inter-RIR ASN Transfers on the RPKI system. Geoff brought up the issue at the NANOG PPC in Bellevue, To respond to a private query, Geoff's comments can be reviewed at https://www.arin.net/participate/meetings/reports/ppc_nanog61/ppc_transcript.html#anchor_14 -Scott and the subsequent staff assessment highlighted the fact that ARIN would need to do additional RPKI development to make Inter-RIR ASN transfers work with RPKI. Therefore, most of the AC felt (and convinced me) that we shouldn't recommend ARIN-2014-15 for adoption after Baltimore, but rather should leave it as a Draft Policy and discuss the RPKI issues there. -Scott ------------------------------------------------------------------------------ _______________________________________________ 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 andrew.dul at quark.net Wed Jul 23 17:45:54 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 23 Jul 2014 14:45:54 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <53CFED3B.7090604@umn.edu> References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> Message-ID: <53D02D12.30506@quark.net> On 7/23/2014 10:13 AM, David Farmer wrote: > On 7/23/14, 10:27 , ARIN wrote: > ... >> Recommended Draft Policy ARIN-2014-9 >> Resolve Conflict Between RSA and 8.2 Utilization Requirements >> >> Date: 23 July 2014 >> >> AC's assessment of conformance with the Principles of Internet Number >> Resource Policy: >> >> "This proposal enables fair and impartial number resource administration >> by eliminating conflicting language in the NRPM with the RSA. This >> proposal is technically sound. The NRPM should not contain language that >> conflicts with the RSA. This proposal is supported by the community. >> This proposal reflects current practice." >> >> Problem Statement: >> >> 8.2 transfer policy has utilization requirements at the time of the >> review of the transfer request. >> >> The RSA section 6 expressly forbids ARIN from de-registering blocks (in >> whole or in part) due to under-utilization or no-justification during >> transfer requests. >> >> This is a direct conflict. >> >> Policy statement: >> >> Remove the words "aggregate" and "reclaim" from 8.2, so it reads: >> >> "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." > > While I support the original version of this policy that completely > removed this clause and the requirement for a resource review as part > of an 8.2 transfer. I also support this version that removes the > words "aggregate" and "reclaim" from 8.2. I believe it is absolutely > necessary to resolve the conflict described in the problem statement > and this policy text accomplishes that goal. > > While I support eliminating the requirement for a resource review as > part of an 8.2 transfer, I feel that goes beyond what is minimally > necessary to resolve the conflict described in the problem statement. > I do not support this draft policy as written. This current draft does not do anything substantive to fix the conflict in the NRPM which exists because the RSA contractually obligates ARIN not to reclaim address space for underutilization. The current 8.2 policy and this proposed draft change will still result in orphan blocks with incorrect stale registry information even when legitimate network mergers and acquisitions occur. The RSA is the controlling document between an organization and ARIN, and the NRPM should not have policy which directly contradicts the contractual limitations or obligations of the RSA. Andrew From scottleibrand at gmail.com Wed Jul 23 18:00:14 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Jul 2014 15:00:14 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <53D02D12.30506@quark.net> References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> Message-ID: On Wed, Jul 23, 2014 at 2:45 PM, Andrew Dul wrote: > > > On 7/23/14, 10:27 , ARIN wrote: > > ... > >> Recommended Draft Policy ARIN-2014-9 > >> Resolve Conflict Between RSA and 8.2 Utilization Requirements > >> > >> Date: 23 July 2014 > >> > >> AC's assessment of conformance with the Principles of Internet Number > >> Resource Policy: > >> > >> "This proposal enables fair and impartial number resource administration > >> by eliminating conflicting language in the NRPM with the RSA. This > >> proposal is technically sound. The NRPM should not contain language that > >> conflicts with the RSA. This proposal is supported by the community. > >> This proposal reflects current practice." > >> > >> Problem Statement: > >> > >> 8.2 transfer policy has utilization requirements at the time of the > >> review of the transfer request. > >> > >> The RSA section 6 expressly forbids ARIN from de-registering blocks (in > >> whole or in part) due to under-utilization or no-justification during > >> transfer requests. > >> > >> This is a direct conflict. > >> > >> Policy statement: > >> > >> Remove the words "aggregate" and "reclaim" from 8.2, so it reads: > >> > >> "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." > > > > I do not support this draft policy as written. > > This current draft does not do anything substantive to fix the conflict > in the NRPM which exists because the RSA contractually obligates ARIN > not to reclaim address space for underutilization. You are correct that the RSA contractually obligates ARIN not to reclaim address space. That is why ARIN-2014-9 removes that word ("reclaim"). Given that, I'm not sure why you say that this "doesn't do anything substantive to fix the conflict". > The current 8.2 > policy and this proposed draft change will still result in orphan blocks > with incorrect stale registry information even when legitimate network > mergers and acquisitions occur. > Why do you say that? Do you feel that when organizations acquire space via M&A, they will be afraid of ARIN working with them to voluntarily return or transfer unneeded resources, and will instead fail to tell ARIN about the transaction? I understand that fear based on the current language (which threatens reclamation), but I'm having trouble understanding how that would remain a concern once all ARIN is directed to do is work with the resource holder to do something voluntary. > > The RSA is the controlling document between an organization and ARIN, > and the NRPM should not have policy which directly contradicts the > contractual limitations or obligations of the RSA. > I do not see how the remaining language ("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.") directly (or indirectly) contradicts the contractual limitations or obligations of the RSA. Perhaps you could provide more details on why you think it does? Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Wed Jul 23 19:03:03 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 23 Jul 2014 16:03:03 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> Message-ID: <53D03F27.6030206@quark.net> On 7/23/2014 3:00 PM, Scott Leibrand wrote: > On Wed, Jul 23, 2014 at 2:45 PM, Andrew Dul > wrote: > > > > On 7/23/14, 10:27 , ARIN wrote: > > ... > >> Recommended Draft Policy ARIN-2014-9 > >> Resolve Conflict Between RSA and 8.2 Utilization Requirements > >> > >> Date: 23 July 2014 > >> > >> AC's assessment of conformance with the Principles of Internet > Number > >> Resource Policy: > >> > >> "This proposal enables fair and impartial number resource > administration > >> by eliminating conflicting language in the NRPM with the RSA. This > >> proposal is technically sound. The NRPM should not contain > language that > >> conflicts with the RSA. This proposal is supported by the > community. > >> This proposal reflects current practice." > >> > >> Problem Statement: > >> > >> 8.2 transfer policy has utilization requirements at the time of the > >> review of the transfer request. > >> > >> The RSA section 6 expressly forbids ARIN from de-registering > blocks (in > >> whole or in part) due to under-utilization or no-justification > during > >> transfer requests. > >> > >> This is a direct conflict. > >> > >> Policy statement: > >> > >> Remove the words "aggregate" and "reclaim" from 8.2, so it reads: > >> > >> "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." > > > > I do not support this draft policy as written. > > This current draft does not do anything substantive to fix the > conflict > in the NRPM which exists because the RSA contractually obligates ARIN > not to reclaim address space for underutilization. > > > You are correct that the RSA contractually obligates ARIN not to > reclaim address space. That is why ARIN-2014-9 removes that word > ("reclaim"). Given that, I'm not sure why you say that this "doesn't > do anything substantive to fix the conflict". ARIN today can't reclaim the space nor force an organization it to aggregate because of the RSA terms, so those two words being in the NRPM don't do anything. So removing them doesn't do anything either, in my opinion. The real issue is in the utilization requirement on 8.2 transfers. > > > The current 8.2 > policy and this proposed draft change will still result in orphan > blocks > with incorrect stale registry information even when legitimate network > mergers and acquisitions occur. > > > Why do you say that? Do you feel that when organizations acquire > space via M&A, they will be afraid of ARIN working with them to > voluntarily return or transfer unneeded resources, and will instead > fail to tell ARIN about the transaction? I understand that fear based > on the current language (which threatens reclamation), but I'm having > trouble understanding how that would remain a concern once all ARIN is > directed to do is work with the resource holder to do something voluntary. Org A purchases Org B (and its network). Org A asks ARIN to update Org B's records to show that Org A now owns Org B. Org B's address space is vastly underutilized and Org A+B's combined growth doesn't meet current policy utilization requirements for Org B's netblocks. The current 8.2 policy prevents ARIN from updating Org B's netblocks to show that Org A now is the legitimate rights holder for Org B's netblocks because it doesn't meet the utilization requirements in 8.2. Org A estimates it would take $x million dollars to migrate all the services currently scattered in Org B's netblocks into other blocks so that some blocks could be transferred or returned. Org A gives up on the 8.2 transfer request, and thus we end up with Org B's records being orphaned with incorrect registration information. Someone from Org A continues to pay the maintenance or membership fees for Org B (if its not legacy non-LRSA) and the registry records continue to _not_ show Org A as the legitimate rights holder for Org B's netblocks. > > > > The RSA is the controlling document between an organization and ARIN, > and the NRPM should not have policy which directly contradicts the > contractual limitations or obligations of the RSA. > > > I do not see how the remaining language ("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.") > directly (or indirectly) contradicts the contractual limitations or > obligations of the RSA. Perhaps you could provide more details on why > you think it does? > If an organization voluntarily wants to return or transfer address space that is fine. However, if the blocks aren't utilized to today's utilization policies, an org may choose not to update their records because that is easier and in their best interest. I postulate that it is better to let legitimate M&A activities show the actual rights older of the address blocks, rather than previous holders even if that allows transfers to occur for underutilized netblocks. The hypothetical above shows how an organization even with the best intentions to keep their registry data up-to-date will make a business decision to just continue like the transfer never occurred from a registry data perspective. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Wed Jul 23 19:15:38 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 23 Jul 2014 19:15:38 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <53D03F27.6030206@quark.net> References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> Message-ID: ARIN also can't reclaim legacy resources. No op. Agreed, another Internet cat video. Best, -M< On Wednesday, July 23, 2014, Andrew Dul wrote: > On 7/23/2014 3:00 PM, Scott Leibrand wrote: > > On Wed, Jul 23, 2014 at 2:45 PM, Andrew Dul > wrote: > >> >> > On 7/23/14, 10:27 , ARIN wrote: >> > ... >> >> Recommended Draft Policy ARIN-2014-9 >> >> Resolve Conflict Between RSA and 8.2 Utilization Requirements >> >> >> >> Date: 23 July 2014 >> >> >> >> AC's assessment of conformance with the Principles of Internet Number >> >> Resource Policy: >> >> >> >> "This proposal enables fair and impartial number resource >> administration >> >> by eliminating conflicting language in the NRPM with the RSA. This >> >> proposal is technically sound. The NRPM should not contain language >> that >> >> conflicts with the RSA. This proposal is supported by the community. >> >> This proposal reflects current practice." >> >> >> >> Problem Statement: >> >> >> >> 8.2 transfer policy has utilization requirements at the time of the >> >> review of the transfer request. >> >> >> >> The RSA section 6 expressly forbids ARIN from de-registering blocks (in >> >> whole or in part) due to under-utilization or no-justification during >> >> transfer requests. >> >> >> >> This is a direct conflict. >> >> >> >> Policy statement: >> >> >> >> Remove the words "aggregate" and "reclaim" from 8.2, so it reads: >> >> >> >> "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." >> > >> >> I do not support this draft policy as written. >> >> This current draft does not do anything substantive to fix the conflict >> in the NRPM which exists because the RSA contractually obligates ARIN >> not to reclaim address space for underutilization. > > > You are correct that the RSA contractually obligates ARIN not to reclaim > address space. That is why ARIN-2014-9 removes that word ("reclaim"). > Given that, I'm not sure why you say that this "doesn't do anything > substantive to fix the conflict". > > > ARIN today can't reclaim the space nor force an organization it to > aggregate because of the RSA terms, so those two words being in the NRPM > don't do anything. So removing them doesn't do anything either, in my > opinion. The real issue is in the utilization requirement on 8.2 transfers. > > > >> The current 8.2 >> policy and this proposed draft change will still result in orphan blocks >> with incorrect stale registry information even when legitimate network >> mergers and acquisitions occur. >> > > Why do you say that? Do you feel that when organizations acquire space > via M&A, they will be afraid of ARIN working with them to voluntarily > return or transfer unneeded resources, and will instead fail to tell ARIN > about the transaction? I understand that fear based on the current > language (which threatens reclamation), but I'm having trouble > understanding how that would remain a concern once all ARIN is directed to > do is work with the resource holder to do something voluntary. > > > Org A purchases Org B (and its network). Org A asks ARIN to update Org > B's records to show that Org A now owns Org B. Org B's address space is > vastly underutilized and Org A+B's combined growth doesn't meet current > policy utilization requirements for Org B's netblocks. The current 8.2 > policy prevents ARIN from updating Org B's netblocks to show that Org A now > is the legitimate rights holder for Org B's netblocks because it doesn't > meet the utilization requirements in 8.2. Org A estimates it would take $x > million dollars to migrate all the services currently scattered in Org B's > netblocks into other blocks so that some blocks could be transferred or > returned. Org A gives up on the 8.2 transfer request, and thus we end up > with Org B's records being orphaned with incorrect registration > information. Someone from Org A continues to pay the maintenance or > membership fees for Org B (if its not legacy non-LRSA) and the registry > records continue to _not_ show Org A as the legitimate rights holder for > Org B's netblocks. > > > >> >> The RSA is the controlling document between an organization and ARIN, >> and the NRPM should not have policy which directly contradicts the >> contractual limitations or obligations of the RSA. >> > > I do not see how the remaining language ("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.") directly (or indirectly) > contradicts the contractual limitations or obligations of the RSA. Perhaps > you could provide more details on why you think it does? > > > If an organization voluntarily wants to return or transfer address space > that is fine. However, if the blocks aren't utilized to today's > utilization policies, an org may choose not to update their records because > that is easier and in their best interest. I postulate that it is better > to let legitimate M&A activities show the actual rights older of the > address blocks, rather than previous holders even if that allows transfers > to occur for underutilized netblocks. The hypothetical above shows how an > organization even with the best intentions to keep their registry data > up-to-date will make a business decision to just continue like the transfer > never occurred from a registry data perspective. > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Wed Jul 23 19:29:20 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 23 Jul 2014 23:29:20 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <53CFD44B.8040309@arin.net> References: <53CFD44B.8040309@arin.net> Message-ID: On Wed, Jul 23, 2014 at 3:27 PM, ARIN wrote: > Recommended Draft Policy ARIN-2014-9 > Resolve Conflict Between RSA and 8.2 Utilization Requirements > > On 17 July 2014 the ARIN Advisory Council (AC) recommended > ARIN-2014-9 for adoption, making it a Recommended Draft Policy. I am in support of this policy (fixing such conflicts is a good thing), but I am not convinced that in practice it will have noticeable impact on 8.2 registration updates. I will be happy to be found wrong. From scottleibrand at gmail.com Wed Jul 23 20:28:54 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Jul 2014 17:28:54 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <53D03F27.6030206@quark.net> References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> Message-ID: Ok, I think I understand what you're concerned about. But I think that's a different issue, which isn't caused by a conflict with the NRPM, but rather is caused by ARIN's operational practice (correct me if I'm wrong, John) of requiring 50% utilization of acquired space to complete an 8.2 transfer. Maybe it would be useful if ARIN staff could detail what the operational practice is in the case of an 8.2 transfer request of dramatically underutilized space? I agree with you (and the intent of this proposal is) that it'd be best for ARIN to complete the 8.2 transfer, and then (as this policy states) work with the resource holder(s) to return or transfer whatever portions of the transferred space are unused. Obviously the degree to which the acquirer could do that would be determined by just how fragmented the space is. If it's so fragmented that it's not worth renumbering out of or 8.3 transferring any of the space, then I think the proper thing to do is to instruct the acquiring company that any future growth needs to use the unused fragments, and that they will not qualify to receive any new space until they've done so. -Scott On Wed, Jul 23, 2014 at 4:03 PM, Andrew Dul wrote: > On 7/23/2014 3:00 PM, Scott Leibrand wrote: > > On Wed, Jul 23, 2014 at 2:45 PM, Andrew Dul wrote: > >> >> > On 7/23/14, 10:27 , ARIN wrote: >> > ... >> >> Recommended Draft Policy ARIN-2014-9 >> >> Resolve Conflict Between RSA and 8.2 Utilization Requirements >> >> >> >> Date: 23 July 2014 >> >> >> >> AC's assessment of conformance with the Principles of Internet Number >> >> Resource Policy: >> >> >> >> "This proposal enables fair and impartial number resource >> administration >> >> by eliminating conflicting language in the NRPM with the RSA. This >> >> proposal is technically sound. The NRPM should not contain language >> that >> >> conflicts with the RSA. This proposal is supported by the community. >> >> This proposal reflects current practice." >> >> >> >> Problem Statement: >> >> >> >> 8.2 transfer policy has utilization requirements at the time of the >> >> review of the transfer request. >> >> >> >> The RSA section 6 expressly forbids ARIN from de-registering blocks (in >> >> whole or in part) due to under-utilization or no-justification during >> >> transfer requests. >> >> >> >> This is a direct conflict. >> >> >> >> Policy statement: >> >> >> >> Remove the words "aggregate" and "reclaim" from 8.2, so it reads: >> >> >> >> "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." >> > >> >> I do not support this draft policy as written. >> >> This current draft does not do anything substantive to fix the conflict >> in the NRPM which exists because the RSA contractually obligates ARIN >> not to reclaim address space for underutilization. > > > You are correct that the RSA contractually obligates ARIN not to reclaim > address space. That is why ARIN-2014-9 removes that word ("reclaim"). > Given that, I'm not sure why you say that this "doesn't do anything > substantive to fix the conflict". > > > ARIN today can't reclaim the space nor force an organization it to > aggregate because of the RSA terms, so those two words being in the NRPM > don't do anything. So removing them doesn't do anything either, in my > opinion. The real issue is in the utilization requirement on 8.2 transfers. > > > > >> The current 8.2 >> policy and this proposed draft change will still result in orphan blocks >> with incorrect stale registry information even when legitimate network >> mergers and acquisitions occur. >> > > Why do you say that? Do you feel that when organizations acquire space > via M&A, they will be afraid of ARIN working with them to voluntarily > return or transfer unneeded resources, and will instead fail to tell ARIN > about the transaction? I understand that fear based on the current > language (which threatens reclamation), but I'm having trouble > understanding how that would remain a concern once all ARIN is directed to > do is work with the resource holder to do something voluntary. > > > Org A purchases Org B (and its network). Org A asks ARIN to update Org > B's records to show that Org A now owns Org B. Org B's address space is > vastly underutilized and Org A+B's combined growth doesn't meet current > policy utilization requirements for Org B's netblocks. The current 8.2 > policy prevents ARIN from updating Org B's netblocks to show that Org A now > is the legitimate rights holder for Org B's netblocks because it doesn't > meet the utilization requirements in 8.2. Org A estimates it would take $x > million dollars to migrate all the services currently scattered in Org B's > netblocks into other blocks so that some blocks could be transferred or > returned. Org A gives up on the 8.2 transfer request, and thus we end up > with Org B's records being orphaned with incorrect registration > information. Someone from Org A continues to pay the maintenance or > membership fees for Org B (if its not legacy non-LRSA) and the registry > records continue to _not_ show Org A as the legitimate rights holder for > Org B's netblocks. > > > > >> >> The RSA is the controlling document between an organization and ARIN, >> and the NRPM should not have policy which directly contradicts the >> contractual limitations or obligations of the RSA. >> > > I do not see how the remaining language ("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.") directly (or indirectly) > contradicts the contractual limitations or obligations of the RSA. Perhaps > you could provide more details on why you think it does? > > > If an organization voluntarily wants to return or transfer address space > that is fine. However, if the blocks aren't utilized to today's > utilization policies, an org may choose not to update their records because > that is easier and in their best interest. I postulate that it is better > to let legitimate M&A activities show the actual rights older of the > address blocks, rather than previous holders even if that allows transfers > to occur for underutilized netblocks. The hypothetical above shows how an > organization even with the best intentions to keep their registry data > up-to-date will make a business decision to just continue like the transfer > never occurred from a registry data perspective. > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Jul 23 21:28:02 2014 From: jcurran at arin.net (John Curran) Date: Thu, 24 Jul 2014 01:28:02 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> Message-ID: On Jul 23, 2014, at 8:28 PM, Scott Leibrand wrote: > Ok, I think I understand what you're concerned about. But I think that's a different issue, which isn't caused by a conflict with the NRPM, but rather is caused by ARIN's operational practice (correct me if I'm wrong, John) of requiring 50% utilization of acquired space to complete an 8.2 transfer. Maybe it would be useful if ARIN staff could detail what the operational practice is in the case of an 8.2 transfer request of dramatically underutilized space? Scott - If the combined resources of an NRPM 8.2 transfer appear less than 50% utilized, we ask for their 3, 6 and 12 month projections and as long as they show projected usage of at least 50% of the block within one year, we approve the transfer. If they don't project at least 50% utilization within one year, we work with them to return or transfer space to come into compliance. We use the 50% utilization criteria which is presently documented in the end user policy, as that is the most generous interpretation of the NRPM 8.2 language (i.e. "justified under ARIN policy") available. Adoption of ARIN-2014-9 as written would not change this practice, only make clear that we are not reclaiming blocks in this situation. Thanks! /John John Curran President and CEO ARIN From matthew at matthew.at Wed Jul 23 22:00:27 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 23 Jul 2014 19:00:27 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> Message-ID: <27F6DB9B-C0C4-4CE5-BC8B-DF849A6B7914@matthew.at> And people wonder why most M&A goes unrecorded in whois... Matthew Kaufman (Sent from my iPhone) > On Jul 23, 2014, at 6:28 PM, John Curran wrote: > >> On Jul 23, 2014, at 8:28 PM, Scott Leibrand wrote: >> >> Ok, I think I understand what you're concerned about. But I think that's a different issue, which isn't caused by a conflict with the NRPM, but rather is caused by ARIN's operational practice (correct me if I'm wrong, John) of requiring 50% utilization of acquired space to complete an 8.2 transfer. Maybe it would be useful if ARIN staff could detail what the operational practice is in the case of an 8.2 transfer request of dramatically underutilized space? > > Scott - > > If the combined resources of an NRPM 8.2 transfer appear less than 50% utilized, we ask for their > 3, 6 and 12 month projections and as long as they show projected usage of at least 50% of the > block within one year, we approve the transfer. If they don't project at least 50% utilization within > one year, we work with them to return or transfer space to come into compliance. > > We use the 50% utilization criteria which is presently documented in the end user policy, as that > is the most generous interpretation of the NRPM 8.2 language (i.e. "justified under ARIN policy") > available. Adoption of ARIN-2014-9 as written would not change this practice, only make clear > that we are not reclaiming blocks in this situation. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Jul 24 00:20:16 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Jul 2014 21:20:16 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <27F6DB9B-C0C4-4CE5-BC8B-DF849A6B7914@matthew.at> References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> <27F6DB9B-C0C4-4CE5-BC8B-DF849A6B7914@matthew.at> Message-ID: <13B8056B-5BE2-42BE-88A7-BE821B9C7F04@delong.com> Please back this assertion up with actual evidence. Owen On Jul 23, 2014, at 7:00 PM, Matthew Kaufman wrote: > And people wonder why most M&A goes unrecorded in whois... > > Matthew Kaufman > > (Sent from my iPhone) > >> On Jul 23, 2014, at 6:28 PM, John Curran wrote: >> >>> On Jul 23, 2014, at 8:28 PM, Scott Leibrand wrote: >>> >>> Ok, I think I understand what you're concerned about. But I think that's a different issue, which isn't caused by a conflict with the NRPM, but rather is caused by ARIN's operational practice (correct me if I'm wrong, John) of requiring 50% utilization of acquired space to complete an 8.2 transfer. Maybe it would be useful if ARIN staff could detail what the operational practice is in the case of an 8.2 transfer request of dramatically underutilized space? >> >> Scott - >> >> If the combined resources of an NRPM 8.2 transfer appear less than 50% utilized, we ask for their >> 3, 6 and 12 month projections and as long as they show projected usage of at least 50% of the >> block within one year, we approve the transfer. If they don't project at least 50% utilization within >> one year, we work with them to return or transfer space to come into compliance. >> >> We use the 50% utilization criteria which is presently documented in the end user policy, as that >> is the most generous interpretation of the NRPM 8.2 language (i.e. "justified under ARIN policy") >> available. Adoption of ARIN-2014-9 as written would not change this practice, only make clear >> that we are not reclaiming blocks in this situation. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > 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 Jul 24 00:20:53 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 24 Jul 2014 00:20:53 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <13B8056B-5BE2-42BE-88A7-BE821B9C7F04@delong.com> References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> <27F6DB9B-C0C4-4CE5-BC8B-DF849A6B7914@matthew.at> <13B8056B-5BE2-42BE-88A7-BE821B9C7F04@delong.com> Message-ID: <6012A5EC-46A8-42DE-AAB8-BD24B467D9C5@gmail.com> Some of us would, but we fear retribution. Best, -M< > On Jul 24, 2014, at 0:20, Owen DeLong wrote: > > Please back this assertion up with actual evidence. > > Owen > >> On Jul 23, 2014, at 7:00 PM, Matthew Kaufman wrote: >> >> And people wonder why most M&A goes unrecorded in whois... >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >>>> On Jul 23, 2014, at 6:28 PM, John Curran wrote: >>>> >>>> On Jul 23, 2014, at 8:28 PM, Scott Leibrand wrote: >>>> >>>> Ok, I think I understand what you're concerned about. But I think that's a different issue, which isn't caused by a conflict with the NRPM, but rather is caused by ARIN's operational practice (correct me if I'm wrong, John) of requiring 50% utilization of acquired space to complete an 8.2 transfer. Maybe it would be useful if ARIN staff could detail what the operational practice is in the case of an 8.2 transfer request of dramatically underutilized space? >>> >>> Scott - >>> >>> If the combined resources of an NRPM 8.2 transfer appear less than 50% utilized, we ask for their >>> 3, 6 and 12 month projections and as long as they show projected usage of at least 50% of the >>> block within one year, we approve the transfer. If they don't project at least 50% utilization within >>> one year, we work with them to return or transfer space to come into compliance. >>> >>> We use the 50% utilization criteria which is presently documented in the end user policy, as that >>> is the most generous interpretation of the NRPM 8.2 language (i.e. "justified under ARIN policy") >>> available. Adoption of ARIN-2014-9 as written would not change this practice, only make clear >>> that we are not reclaiming blocks in this situation. >>> >>> Thanks! >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> 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 Thu Jul 24 09:19:53 2014 From: jcurran at arin.net (John Curran) Date: Thu, 24 Jul 2014 13:19:53 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: <27F6DB9B-C0C4-4CE5-BC8B-DF849A6B7914@matthew.at> References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> <27F6DB9B-C0C4-4CE5-BC8B-DF849A6B7914@matthew.at> Message-ID: On Jul 23, 2014, at 10:00 PM, Matthew Kaufman wrote: > And people wonder why most M&A goes unrecorded in whois... Matthew - Is the cause of your concern: 1) ARIN's implementation of current NRPM 8.2 (M&A Transfer) policy, which has ARIN work with organizations whose resources are no longer justified under ARIN policy)? If so, I would welcome any suggestions for improvement in the implementation of this policy language. 2) The NRPM 8.2 policy itself? If this is the case, then proposing a policy change which meets your expectations would probably be the best course forward. 3) Parties expectation that their number resources would be transferred contrary to the community-developed policy? We do explain that number resources can only be transferred in accordance with the community-developed policy, and actually have perform hundreds of transfers each year as a result of bona fide merger and acquisition activity (i.e. the vast majority of the requests complete, as one can tell from the statistics - Do you suggest we do more outreach so that those few who attempt to do "M&A transfers" to circumvent NRPM 8.3/8.4 know in advance that they will not be approved? Thanks! /John John Curran President and CEO ARIN From kkargel at polartel.com Thu Jul 24 10:25:50 2014 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 24 Jul 2014 09:25:50 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: References: <53CFCD7A.8060809@arin.net> <5670932556CD48E09C1A211A911330A9@MPC> Message-ID: <8695009A81378E48879980039EEDAD28013AC4FB89@MAIL1.polartel.local> I want one! Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Gary Buhrmaster > Sent: Wednesday, July 23, 2014 1:10 PM > To: Mike Burns > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum > Allocations and Assignments > > On Wed, Jul 23, 2014 at 5:44 PM, Mike Burns wrote: > > ..... How else are we going to get rid of the more than > > 1,000 /24s left as the dregs of decades of allocations? > > Well, you could always reintroduce the proposal that everyone who > commented (on that proposal proposal) would get a /24 given to them. It > would likely increase PPML participation for a short period. > _______________________________________________ > 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 dogwallah at gmail.com Thu Jul 24 11:02:12 2014 From: dogwallah at gmail.com (McTim) Date: Thu, 24 Jul 2014 10:02:12 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: <8695009A81378E48879980039EEDAD28013AC4FB89@MAIL1.polartel.local> References: <53CFCD7A.8060809@arin.net> <5670932556CD48E09C1A211A911330A9@MPC> <8695009A81378E48879980039EEDAD28013AC4FB89@MAIL1.polartel.local> Message-ID: On Thu, Jul 24, 2014 at 9:25 AM, Kevin Kargel wrote: > I want one! > Kevin me too, and a pony please! Opposed for the reasons that Gary has given. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From cblecker at gmail.com Thu Jul 24 11:35:51 2014 From: cblecker at gmail.com (Christoph Blecker) Date: Thu, 24 Jul 2014 08:35:51 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: <53CFCD7A.8060809@arin.net> References: <53CFCD7A.8060809@arin.net> Message-ID: Opposed, based on reasons already provided in this thread. Cheers, Christoph On Wed, Jul 23, 2014 at 7:58 AM, ARIN wrote: > On 17 July 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-210 > Simplifying Minimum Allocations and Assignments" as a Draft Policy. > > Draft Policy ARIN-2014-18 is below and can be found at: > https://www.arin.net/policy/proposals/2014_18.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2014-18 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-2014-18 > Simplifying Minimum Allocations and Assignments > > Date: 23 July 2014 > > Problem Statement: > > New and small organizations are having a difficult time receiving resource > allocations from ARIN because of the economic, administrative and time > burdens of making their way through ARIN?s needs testing process. For small > allocations, the burdens of needs testing may exceed the value of the > resources, or may deter small, less well-funded organizations? ability to > receive an allocation from ARIN. As ARIN was created to provide Internet > resources to ALL organizations within its geographic territory, this > disparity in the Policy Manual needs to be addressed. The problem can be > remedied by removing needs testing for any organization that applies to > receive the current minimum block size allocation. > > Policy statement: > > Therefore I propose the following addition to the Policy Manual (possibly > as 4.2.1.7): > ?A Minimum IP allocation size(s) has been defined per Section 4 of the > ARIN Number Resource Policy Manual. Regardless of any policy requirement(s) > defined in any other active Section of the Policy Manual, all organizations > may apply and shall automatically qualify for the current Minimum IP Block > Allocation upon completing the normal administrative application process > and fee requirements, and all organizations shall be eligible for such an > allocation once every 12 months. Where this is in conflict with any other > Section in the Policy Manual, this Section shall be controlling.? > > Comments: > a. Timetable for implementation: > b. Anything else: > _______________________________________________ > 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 michael at linuxmagic.com Thu Jul 24 11:38:55 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 24 Jul 2014 08:38:55 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: References: <53CFCD7A.8060809@arin.net> Message-ID: <53D1288F.6090208@linuxmagic.com> On 14-07-24 08:35 AM, Christoph Blecker wrote: > Where this is in conflict with any other Section in the Policy Manual, > this Section shall be controlling.? Could it be this line that is creating opposition? I am in favor of allowing smaller allocations.. but maybe there are some very specific areas people are concerned with? -- "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 cblecker at gmail.com Thu Jul 24 11:54:04 2014 From: cblecker at gmail.com (Christoph Blecker) Date: Thu, 24 Jul 2014 08:54:04 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: <53D1288F.6090208@linuxmagic.com> References: <53CFCD7A.8060809@arin.net> <53D1288F.6090208@linuxmagic.com> Message-ID: I think the bigger problem is the concept as a whole. To qualify for a /24 (which will be the new minimum for end users and ISPs alike if the ARIN Board adopts 2014-13, which has been recommended to it), you need to justify the use of 204 addresses in the next three months. This is an extremely low bar to justify. This proposal as written would mean anyone with any kind of business license can just go up to ARIN and get a free /24 every year, no matter if they are actually going to need it or even use it. Doesn't matter if you're a shell corporation, or your local corner store. Free /24 for everybody. Doesn't make a ton of sense. Cheers, Christoph On Thu, Jul 24, 2014 at 8:38 AM, Michael Peddemors wrote: > On 14-07-24 08:35 AM, Christoph Blecker wrote: > >> Where this is in conflict with any other Section in the Policy Manual, >> this Section shall be controlling.? >> > > Could it be this line that is creating opposition? > I am in favor of allowing smaller allocations.. but maybe there are some > very specific areas people are concerned with? > > > -- > "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. > > _______________________________________________ > 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 hannigan at gmail.com Thu Jul 24 17:25:30 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 24 Jul 2014 17:25:30 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments In-Reply-To: References: <53CFCD7A.8060809@arin.net> <53D1288F.6090208@linuxmagic.com> Message-ID: On Thu, Jul 24, 2014 at 11:54 AM, Christoph Blecker wrote: > I think the bigger problem is the concept as a whole. > > To qualify for a /24 (which will be the new minimum for end users and ISPs > alike if the ARIN Board adopts 2014-13, which has been recommended to it), > you need to justify the use of 204 addresses in the next three months. This > is an extremely low bar to justify. > It is extremely low. > > This proposal as written would mean anyone with any kind of business > license can just go up to ARIN and get a free /24 every year, no matter if > they are actually going to need it or even use it. Doesn't matter if you're > a shell corporation, or your local corner store. Free /24 for everybody. > I'm not sure it's attractive to abusers though. $79 to form a corp in FL and I believe an EIN is free, which you don't need to form the corp. A year waiting period if I read the badly written transfer language correctly. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 25 00:05:20 2014 From: jcurran at arin.net (John Curran) Date: Fri, 25 Jul 2014 04:05:20 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements In-Reply-To: References: <53CFD44B.8040309@arin.net> <53CFED3B.7090604@umn.edu> <53D02D12.30506@quark.net> <53D03F27.6030206@quark.net> Message-ID: <491D878A-25FD-41E2-9447-34C14BA13A91@corp.arin.net> On Jul 23, 2014, at 7:15 PM, Martin Hannigan wrote: > ARIN also can't reclaim legacy resources. No op. ARIN does reclaim legacy resources on occasion; this is generally either in compliance with terms of an LRSA for lack of payment or due to the dissolution of an organization with no successor (as non-existant entities cannot hold number resources.) Resources recovered in this manner are are held for 60 days and then placed in the available pool. FYI, /John John Curran President and CEO ARIN From narten at us.ibm.com Fri Jul 25 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 25 Jul 2014 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201407250453.s6P4r2dA024323@rotala.raleigh.ibm.com> Total of 44 messages in the last 7 days. script run at: Fri Jul 25 00:53:02 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 6.82% | 3 | 20.29% | 122752 | sryerse at eclipse-networks.com 9.09% | 4 | 12.97% | 78484 | owen at delong.com 9.09% | 4 | 9.52% | 57583 | scottleibrand at gmail.com 6.82% | 3 | 11.40% | 68970 | cblecker at gmail.com 11.36% | 5 | 5.06% | 30627 | gary.buhrmaster at gmail.com 6.82% | 3 | 6.63% | 40127 | hannigan at gmail.com 6.82% | 3 | 3.76% | 22772 | info at arin.net 6.82% | 3 | 3.42% | 20700 | michael at linuxmagic.com 6.82% | 3 | 3.42% | 20664 | jcurran at arin.net 4.55% | 2 | 5.20% | 31441 | andrew.dul at quark.net 4.55% | 2 | 3.75% | 22699 | mike at iptrading.com 2.27% | 1 | 4.96% | 29996 | mpetach at netflight.com 4.55% | 2 | 2.37% | 14335 | rbf+arin-ppml at panix.com 2.27% | 1 | 1.50% | 9084 | ikiris at gmail.com 2.27% | 1 | 1.42% | 8572 | farmer at umn.edu 2.27% | 1 | 1.20% | 7239 | narten at us.ibm.com 2.27% | 1 | 1.13% | 6836 | matthew at matthew.at 2.27% | 1 | 1.03% | 6216 | kkargel at polartel.com 2.27% | 1 | 0.99% | 5978 | dogwallah at gmail.com --------+------+--------+----------+------------------------ 100.00% | 44 |100.00% | 605075 | Total From mueller at syr.edu Fri Jul 25 02:29:47 2014 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 25 Jul 2014 06:29:47 +0000 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) Message-ID: <945b27c5793b42e2b408dbda0c2c7e8e@EX13-MBX-13.ad.syr.edu> At the Chicago meeting there was support for this policy but also calls for simplifying and shortening it. This is the revised version. ---- Draft Policy ARIN-2014-1 Out of Region Use Date: 21 July 2014 Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has restricting out of region use in various ways. None of these proposals have gained consensus. The next logical option is to discuss a proposal that clearly permits out of region use. Permitting out of region use, however, poses issues that have to be addressed by policy and adjustments to operational practice. Out of region use must be clearly defined and any operational practices based on that definition must not be unnecessarily burdensome. Also, it is more difficult and costly for ARIN staff to independently verify the justification and utilization of resources that are used outside of the ARIN service region. There needs to be recognition of this difference in policy and associated operational practices. Policy statement: Create new Section X; X. Out of region use ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. A resource is considered to be used outside the region if it exclusively serves a user, customer or technical infrastructure location outside the ARIN service region. The services and facilities used to justify the need for ARIN resources that will be used out of region should not also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region and is more than the equivalent of a /20 for IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization will also report to ARIN the utilization status of all resources of the same type held with any other RIR that are used or are available for use within the requested service region. The organization will also supply any additional supporting documentation requested by ARIN regarding the need for the reported resources. The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sweeting at twcable.com Fri Jul 25 09:01:58 2014 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 25 Jul 2014 09:01:58 -0400 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) Message-ID: Good morning PPML, Please provide comments in support or opposition as the plan is to vote to move this to Recommended Draft Status for the Baltimore meeting. Thanks, John On 7/25/14, 2:29 AM, "Milton L Mueller" > wrote: At the Chicago meeting there was support for this policy but also calls for simplifying and shortening it. This is the revised version. ---- Draft Policy ARIN-2014-1 Out of Region Use Date: 21 July 2014 Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has restricting out of region use in various ways. None of these proposals have gained consensus. The next logical option is to discuss a proposal that clearly permits out of region use. Permitting out of region use, however, poses issues that have to be addressed by policy and adjustments to operational practice. Out of region use must be clearly defined and any operational practices based on that definition must not be unnecessarily burdensome. Also, it is more difficult and costly for ARIN staff to independently verify the justification and utilization of resources that are used outside of the ARIN service region. There needs to be recognition of this difference in policy and associated operational practices. Policy statement: Create new Section X; X. Out of region use ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. A resource is considered to be used outside the region if it exclusively serves a user, customer or technical infrastructure location outside the ARIN service region. The services and facilities used to justify the need for ARIN resources that will be used out of region should not also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR?s service region and is more than the equivalent of a /20 for IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization will also report to ARIN the utilization status of all resources of the same type held with any other RIR that are used or are available for use within the requested service region. The organization will also supply any additional supporting documentation requested by ARIN regarding the need for the reported resources. The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Fri Jul 25 10:14:17 2014 From: jschiller at google.com (Jason Schiller) Date: Fri, 25 Jul 2014 10:14:17 -0400 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: I oppose as written, but support the concept. (I oppose this version more that the previous version) I still have concerns about the hard limit of and IPv4 /20, IPv6 /36 or two ASNs. I think the point here is to ensure that organizations are not double counting equipment to get resources from multiple RIRs for the same use, nor squatting on underutilized IP space from another RIR which could be used and instead getting additional IP space from ARIN. There was some idea in the original policy that this additional burden could be avoided if the out of region use was only "incidental", yielding this /20 text. I argued that a hard limit of a /20 is not a fair dividing line for incidental. Many small organizations will never need more that a /20. Such a large hard limit suggests that the need to prove no double counting or no sitting on underutilized resources from another RIR does not apply to small sites. Either make it a percentage of total such "When a request for resources from ARIN is justified by need located within another RIR's service region and is more than 5% of the total utilization, the requesting organization will also report to ARIN the utilization status of all resources of the same type held with any other RIR that are used or are available for use within the requested service region." Or simply always require it. If the organization does not have resources in other RIRs, there is no burden. The original proposal suggested that when ARIN validates an out of region use, they must be able to validate the use to no less than an equivalent standard as resources used within the ARIN region. This is with respect to ensuring the utilization is nor fraudulent, such as if the customer service address is a verifiable address, if the company name is an actual company, and so on. This proposal seems to go further and suggest that any ARIN space and other RIR space must be efficiently utilized by ARIN's definition of efficient utilization. "The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy." If all the RIRs passed a similar policy global networks would be forced to follow the most strict polices of all the RIRs. In some cases the conflicting requirements could not be met. We had this discussion with the original proposal to prevent out of region use. Furthermore is flies in the face that regional communities have some regional autonomy to deal with local differences. I believe I could get on board with the following two changes: 1. If you drop the hard limit either making it a percentage of total use, or always require reporting of usage of IP space held by other RIRs 2. change " The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy." to some text about ARIN validating out of region space no less than an equivalent standard. possibly "All ARIN registered resources used outside the region must be verified to no less than an equivalent standard as resources used within the ARIN region." ___Jason On Fri, Jul 25, 2014 at 9:01 AM, Sweeting, John wrote: > Good morning PPML, > > Please provide comments in support or opposition as the plan is to vote > to move this to Recommended Draft Status for the Baltimore meeting. > > Thanks, > John > > > On 7/25/14, 2:29 AM, "Milton L Mueller" wrote: > > At the Chicago meeting there was support for this policy but also > calls for simplifying and shortening it. This is the revised version. > > ---- > > Draft Policy ARIN-2014-1 > Out of Region Use > > Date: 21 July 2014 > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out of region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on this > issue has restricting out of region use in various ways. None of these > proposals have gained consensus. The next logical option is to discuss a > proposal that clearly permits out of region use. Permitting out of region > use, however, poses issues that have to be addressed by policy and > adjustments to operational practice. Out of region use must be clearly > defined and any operational practices based on that definition must not be > unnecessarily burdensome. Also, it is more difficult and costly for ARIN > staff to independently verify the justification and utilization of > resources that are used outside of the ARIN service region. There needs to > be recognition of this difference in policy and associated operational > practices. > > Policy statement: > > Create new Section X; > > X. Out of region use > > ARIN registered resources may be used outside the ARIN service region and > such use is valid justification for new or additional resources. A resource > is considered to be used outside the region if it exclusively serves a > user, customer or technical infrastructure location outside the ARIN > service region. > > > > The services and facilities used to justify the need for ARIN resources > that will be used out of region should not also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR's service region and is more > than the equivalent of a /20 for IPv4, a /36 for IPv6, or two (2) ASNs, the > requesting organization will also report to ARIN the utilization status of > all resources of the same type held with any other RIR that are used or are > available for use within the requested service region. The organization > will also supply any additional supporting documentation requested by ARIN > regarding the need for the reported resources. The report must demonstrate > that all resources currently available for use within the requested service > region are efficiently utilized based on applicable ARIN policy. > > > > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Fri Jul 25 10:59:14 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Fri, 25 Jul 2014 07:59:14 -0700 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: <53D270C2.9040301@linuxmagic.com> I understand the motivation for this policy, ie a typical multi-national, however given the diminishing IP Address pool, I do not have enough information to foresee the overall ramifications. I don't know, something seems to be missing .. ABSTAIN On 14-07-25 06:01 AM, Sweeting, John wrote: > Good morning PPML, > > Please provide comments in support or opposition as the plan is to vote > to move this to Recommended Draft Status for the Baltimore meeting. > > Thanks, > John > > > On 7/25/14, 2:29 AM, "Milton L Mueller" > wrote: > > At the Chicago meeting there was support for this policy but also > calls for simplifying and shortening it. This is the revised version. > > ---- > > Draft Policy ARIN-2014-1 > Out of Region Use > > Date: 21 July 2014 > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out of > region use of ARIN registered resources. This has created confusion > and controversy within the ARIN community for some time. Earlier > work on this issue has restricting out of region use in various > ways. None of these proposals have gained consensus. The next > logical option is to discuss a proposal that clearly permits out of > region use. Permitting out of region use, however, poses issues that > have to be addressed by policy and adjustments to operational > practice. Out of region use must be clearly defined and any > operational practices based on that definition must not be > unnecessarily burdensome. Also, it is more difficult and costly for > ARIN staff to independently verify the justification and utilization > of resources that are used outside of the ARIN service region. There > needs to be recognition of this difference in policy and associated > operational practices. > > Policy statement: > > Create new Section X; > > X. Out of region use > > ARIN registered resources may be used outside the ARIN service > region and such use is valid justification for new or additional > resources. A resource is considered to be used outside the region if > it exclusively serves a user, customer or technical infrastructure > location outside the ARIN service region. > > The services and facilities used to justify the need for ARIN > resources that will be used out of region should not also be used to > justify resource requests from another RIR. When a request for > resources from ARIN is justified by need located within another > RIR?s service region and is more than the equivalent of a /20 for > IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization > will also report to ARIN the utilization status of all resources of > the same type held with any other RIR that are used or are available > for use within the requested service region. The organization will > also supply any additional supporting documentation requested by > ARIN regarding the need for the reported resources. The report must > demonstrate that all resources currently available for use within > the requested service region are efficiently utilized based on > applicable ARIN policy. > > > ------------------------------------------------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is addressed. > If you are not the intended recipient of this E-mail, you are hereby > notified that any dissemination, distribution, copying, or action taken > in relation to the contents of and attachments to this E-mail is > strictly prohibited and may be unlawful. If you have received this > E-mail in error, please notify the sender immediately and permanently > delete the original and any copy of this E-mail and any printout. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- "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 gary.buhrmaster at gmail.com Fri Jul 25 11:23:58 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 25 Jul 2014 15:23:58 +0000 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: On Fri, Jul 25, 2014 at 2:14 PM, Jason Schiller wrote: > I oppose as written, but support the concept. I do not yet have a clear leaning for/against this version of text, but I too have some concerns. I, too, support the concept. .... > There was some idea in the original policy that this additional burden could > be avoided if the out of region use was only "incidental", yielding this /20 text. Yeah, I think we got bogged down in the definition of incidental, and "you know it when you see it" does not fly well as a procedure. .... > This proposal seems to go further and suggest that any ARIN space and other > RIR space must be efficiently utilized by ARIN's definition of efficient > utilization. > > > "The report must demonstrate that all resources currently available for use > within the requested service region are efficiently utilized based on > applicable ARIN policy." Depending on the implied ANDs or ORs, that might requirement may only apply to requests for more the /20's. Could someone (staff?) clarify how this would be interpreted? From SRyerse at eclipse-networks.com Fri Jul 25 11:42:28 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Jul 2014 15:42:28 +0000 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of regionuse) In-Reply-To: References: Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015B37980E@ENI-MAIL.eclipse-networks.com> I would support. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Sweeting, John Sent: Friday, July 25, 2014 9:02 AM To: ARIN PPML (ppml at arin.net) Subject: Re: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of regionuse) Good morning PPML, Please provide comments in support or opposition as the plan is to vote to move this to Recommended Draft Status for the Baltimore meeting. Thanks, John On 7/25/14, 2:29 AM, "Milton L Mueller" > wrote: At the Chicago meeting there was support for this policy but also calls for simplifying and shortening it. This is the revised version. ---- Draft Policy ARIN-2014-1 Out of Region Use Date: 21 July 2014 Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has restricting out of region use in various ways. None of these proposals have gained consensus. The next logical option is to discuss a proposal that clearly permits out of region use. Permitting out of region use, however, poses issues that have to be addressed by policy and adjustments to operational practice. Out of region use must be clearly defined and any operational practices based on that definition must not be unnecessarily burdensome. Also, it is more difficult and costly for ARIN staff to independently verify the justification and utilization of resources that are used outside of the ARIN service region. There needs to be recognition of this difference in policy and associated operational practices. Policy statement: Create new Section X; X. Out of region use ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. A resource is considered to be used outside the region if it exclusively serves a user, customer or technical infrastructure location outside the ARIN service region. The services and facilities used to justify the need for ARIN resources that will be used out of region should not also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR?s service region and is more than the equivalent of a /20 for IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization will also report to ARIN the utilization status of all resources of the same type held with any other RIR that are used or are available for use within the requested service region. The organization will also supply any additional supporting documentation requested by ARIN regarding the need for the reported resources. The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From owen at delong.com Sat Jul 26 13:18:26 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Jul 2014 10:18:26 -0700 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: <53D270C2.9040301@linuxmagic.com> References: <53D270C2.9040301@linuxmagic.com> Message-ID: This would apply not only to IPv4, but to IPv6. While the IPv6 pool is slowly diminishing, I don?t think it is doing so to such an extent as to support your concerns. In the case of IPv4, I believe the IPv4 pool will more than likely be gone before this policy would be implemented, so I think that considering this in an IPv4 context is not all that useful. Owen On Jul 25, 2014, at 7:59 AM, Michael Peddemors wrote: > I understand the motivation for this policy, ie a typical multi-national, however given the diminishing IP Address pool, I do not have enough information to foresee the overall ramifications. > > I don't know, something seems to be missing .. > > ABSTAIN > > > > On 14-07-25 06:01 AM, Sweeting, John wrote: >> Good morning PPML, >> >> Please provide comments in support or opposition as the plan is to vote >> to move this to Recommended Draft Status for the Baltimore meeting. >> >> Thanks, >> John >> >> >> On 7/25/14, 2:29 AM, "Milton L Mueller" > > wrote: >> >> At the Chicago meeting there was support for this policy but also >> calls for simplifying and shortening it. This is the revised version. >> >> ---- >> >> Draft Policy ARIN-2014-1 >> Out of Region Use >> >> Date: 21 July 2014 >> >> Problem statement: >> >> Current policy neither clearly forbids nor clearly permits out of >> region use of ARIN registered resources. This has created confusion >> and controversy within the ARIN community for some time. Earlier >> work on this issue has restricting out of region use in various >> ways. None of these proposals have gained consensus. The next >> logical option is to discuss a proposal that clearly permits out of >> region use. Permitting out of region use, however, poses issues that >> have to be addressed by policy and adjustments to operational >> practice. Out of region use must be clearly defined and any >> operational practices based on that definition must not be >> unnecessarily burdensome. Also, it is more difficult and costly for >> ARIN staff to independently verify the justification and utilization >> of resources that are used outside of the ARIN service region. There >> needs to be recognition of this difference in policy and associated >> operational practices. >> >> Policy statement: >> >> Create new Section X; >> >> X. Out of region use >> >> ARIN registered resources may be used outside the ARIN service >> region and such use is valid justification for new or additional >> resources. A resource is considered to be used outside the region if >> it exclusively serves a user, customer or technical infrastructure >> location outside the ARIN service region. >> >> The services and facilities used to justify the need for ARIN >> resources that will be used out of region should not also be used to >> justify resource requests from another RIR. When a request for >> resources from ARIN is justified by need located within another >> RIR?s service region and is more than the equivalent of a /20 for >> IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization >> will also report to ARIN the utilization status of all resources of >> the same type held with any other RIR that are used or are available >> for use within the requested service region. The organization will >> also supply any additional supporting documentation requested by >> ARIN regarding the need for the reported resources. The report must >> demonstrate that all resources currently available for use within >> the requested service region are efficiently utilized based on >> applicable ARIN policy. >> >> >> ------------------------------------------------------------------------ >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject >> to copyright belonging to Time Warner Cable. This E-mail is intended >> solely for the use of the individual or entity to which it is addressed. >> If you are not the intended recipient of this E-mail, you are hereby >> notified that any dissemination, distribution, copying, or action taken >> in relation to the contents of and attachments to this E-mail is >> strictly prohibited and may be unlawful. If you have received this >> E-mail in error, please notify the sender immediately and permanently >> delete the original and any copy of this E-mail and any printout. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > "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. > _______________________________________________ > 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 mueller at syr.edu Sun Jul 27 02:08:01 2014 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 27 Jul 2014 06:08:01 +0000 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: <9f5d8073a65642629bc8b28af468992d@EX13-MBX-13.ad.syr.edu> Jason From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller >I oppose as written, but support the concept. >(I oppose this version more that the previous version) That's odd, because the previous version had the same hard limits. It was simply defined as "incidental use" and created 3 categories of such use. In this respect, there is no substantive difference between the two versions. This one is just simpler. > There was some idea in the original policy that this additional burden could > be avoided if the out of region use was only "incidental", yielding this /20 text. > I argued that a hard limit of a /20 is not a fair dividing line for incidental. > Many small organizations will never need more that a /20. Such a large hard > limit suggests that the need to prove no double counting or no sitting on > underutilized resources from another RIR does not apply to small sites. It does indeed mean that, and it also means that the time and effort required by ARIN staff to monitor such smaller sites may simply not be worth it. If your point here is that this limit is "unfair" to large organizations you are going to have trouble finding much sympathy here. Larger organizations consume more resources and thus merit closer attention. Fixed reporting costs are, proportionately, a larger cost to small organizations than to larger ones. The fixed limits save ARIN from expending a lot of effort for very small potential gains, and save small orgs from burdensome requirements. For organizations with larger use of number resources, the stakes are higher in terms of resource consumptions and the potential unfairness of double counting, so the extra monitoring effort is worth it. > Either make it a percentage of total such "When a request for resources Earlier proposals by David already explained why percentages don't work. Percentages vary with the total amount of resources one has and thus one could fluctuate in and out of the limit as one grows. That doesn't make sense. Besides, the concept of "incidental use" implies more of an absolute limit than one relative to one's other holdings. "Incidentalness" is relative to ARIN pools, not the users' holdings. >This proposal seems to go further and suggest that any ARIN space and other RIR > space must be efficiently utilized by ARIN's definition of efficient utilization. That was not the intent - the intent was to ensure that only ARIN resources are efficiently utilized by ARIN's standards. >I believe I could get on board with the following two changes: > >1. If you drop the hard limit either making it a percentage of total use, > or always require reporting of usage of IP space held by other RIRs I would not be willing to do that, for reasons stated above. > 2. change " The report must demonstrate that all resources currently available > for use within the requested service region are efficiently utilized based on > applicable ARIN policy." to some text about ARIN validating out of region > space no less than an equivalent standard. possibly "All ARIN registered > resources used outside the region must be verified to no less than an equivalent > standard as resources used within the ARIN region." This sounds OK to me, and I suspect David would not have a problem with it but let him speak for himself. On Fri, Jul 25, 2014 at 9:01 AM, Sweeting, John > wrote: Good morning PPML, Please provide comments in support or opposition as the plan is to vote to move this to Recommended Draft Status for the Baltimore meeting. Thanks, John On 7/25/14, 2:29 AM, "Milton L Mueller" > wrote: At the Chicago meeting there was support for this policy but also calls for simplifying and shortening it. This is the revised version. ---- Draft Policy ARIN-2014-1 Out of Region Use Date: 21 July 2014 Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has restricting out of region use in various ways. None of these proposals have gained consensus. The next logical option is to discuss a proposal that clearly permits out of region use. Permitting out of region use, however, poses issues that have to be addressed by policy and adjustments to operational practice. Out of region use must be clearly defined and any operational practices based on that definition must not be unnecessarily burdensome. Also, it is more difficult and costly for ARIN staff to independently verify the justification and utilization of resources that are used outside of the ARIN service region. There needs to be recognition of this difference in policy and associated operational practices. Policy statement: Create new Section X; X. Out of region use ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. A resource is considered to be used outside the region if it exclusively serves a user, customer or technical infrastructure location outside the ARIN service region. The services and facilities used to justify the need for ARIN resources that will be used out of region should not also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region and is more than the equivalent of a /20 for IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization will also report to ARIN the utilization status of all resources of the same type held with any other RIR that are used or are available for use within the requested service region. The organization will also supply any additional supporting documentation requested by ARIN regarding the need for the reported resources. The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Mon Jul 28 11:43:19 2014 From: jschiller at google.com (Jason Schiller) Date: Mon, 28 Jul 2014 11:43:19 -0400 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: Leslie, Would it be possible to list the number of Org IDs that hold a given amount of /24 equivalents of ARIN IP space? Something like: Number of Orgs /24 equ 60 1 30 2 49 3 100 4 22 7 432 8 I think this may be a useful number in understanding how "incidental" a /20 is. Thanks, __Jason On Fri, Jul 25, 2014 at 10:14 AM, Jason Schiller wrote: > I oppose as written, but support the concept. > (I oppose this version more that the previous version) > > I still have concerns about the hard limit of and IPv4 /20, IPv6 /36 or > two ASNs. > > I think the point here is to ensure that organizations are not double > counting equipment to get resources from multiple RIRs for the same use, > nor squatting on underutilized IP space from another RIR which could be > used and instead getting additional IP space from ARIN. > > There was some idea in the original policy that this additional burden > could be avoided if the out of region use was only "incidental", yielding > this /20 text. I argued that a hard limit of a /20 is not a fair dividing > line for incidental. Many small organizations will never need more that a > /20. Such a large hard limit suggests that the need to prove no double > counting or no sitting on underutilized resources from another RIR does > not apply to small sites. Either make it a percentage of total such "When > a request for resources from ARIN is justified by need located within > another RIR's service region and is more than 5% of the total utilization, > the requesting organization will also report to ARIN the utilization status > of all resources of the same type held with any other RIR that are used or > are available for use within the requested service region." Or simply > always require it. If the organization does not have resources in other > RIRs, there is no burden. > > > The original proposal suggested that when ARIN validates an out of region > use, they must be able to validate the use to no less than an equivalent > standard as resources used within the ARIN region. This is with respect to > ensuring the utilization is nor fraudulent, such as if the customer service > address is a verifiable address, if the company name is an actual company, > and so on. > > This proposal seems to go further and suggest that any ARIN space and > other RIR space must be efficiently utilized by ARIN's definition of > efficient utilization. > > > "The report must demonstrate that all resources currently available for > use within the requested service region are efficiently utilized based on > applicable ARIN policy." > > If all the RIRs passed a similar policy global networks would be forced to > follow the most strict polices of all the RIRs. In some cases the > conflicting requirements could not be met. We had this discussion with the > original proposal to prevent out of region use. Furthermore is flies in > the face that regional communities have some regional autonomy to deal with > local differences. > > > I believe I could get on board with the following two changes: > > 1. If you drop the hard limit either making it a percentage of total use, > or always require reporting of usage of IP space held by other RIRs > > 2. change " The report must demonstrate that all resources currently > available for use within the requested service region are efficiently > utilized based on applicable ARIN policy." to some text about ARIN > validating out of region space no less than an equivalent standard. > possibly "All ARIN registered resources used outside the region must be > verified to no less than an equivalent standard as resources used within > the ARIN region." > > > ___Jason > > > > On Fri, Jul 25, 2014 at 9:01 AM, Sweeting, John > wrote: > >> Good morning PPML, >> >> Please provide comments in support or opposition as the plan is to vote >> to move this to Recommended Draft Status for the Baltimore meeting. >> >> Thanks, >> John >> >> >> On 7/25/14, 2:29 AM, "Milton L Mueller" wrote: >> >> At the Chicago meeting there was support for this policy but also >> calls for simplifying and shortening it. This is the revised version. >> >> ---- >> >> Draft Policy ARIN-2014-1 >> Out of Region Use >> >> Date: 21 July 2014 >> >> Problem statement: >> >> Current policy neither clearly forbids nor clearly permits out of region >> use of ARIN registered resources. This has created confusion and >> controversy within the ARIN community for some time. Earlier work on this >> issue has restricting out of region use in various ways. None of these >> proposals have gained consensus. The next logical option is to discuss a >> proposal that clearly permits out of region use. Permitting out of region >> use, however, poses issues that have to be addressed by policy and >> adjustments to operational practice. Out of region use must be clearly >> defined and any operational practices based on that definition must not be >> unnecessarily burdensome. Also, it is more difficult and costly for ARIN >> staff to independently verify the justification and utilization of >> resources that are used outside of the ARIN service region. There needs to >> be recognition of this difference in policy and associated operational >> practices. >> >> Policy statement: >> >> Create new Section X; >> >> X. Out of region use >> >> ARIN registered resources may be used outside the ARIN service region and >> such use is valid justification for new or additional resources. A resource >> is considered to be used outside the region if it exclusively serves a >> user, customer or technical infrastructure location outside the ARIN >> service region. >> >> >> >> The services and facilities used to justify the need for ARIN resources >> that will be used out of region should not also be used to justify resource >> requests from another RIR. When a request for resources from ARIN is >> justified by need located within another RIR's service region and is more >> than the equivalent of a /20 for IPv4, a /36 for IPv6, or two (2) ASNs, the >> requesting organization will also report to ARIN the utilization status of >> all resources of the same type held with any other RIR that are used or are >> available for use within the requested service region. The organization >> will also supply any additional supporting documentation requested by ARIN >> regarding the need for the reported resources. The report must demonstrate >> that all resources currently available for use within the requested service >> region are efficiently utilized based on applicable ARIN policy. >> >> >> >> >> ------------------------------ >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely >> for the use of the individual or entity to which it is addressed. If you >> are not the intended recipient of this E-mail, you are hereby notified that >> any dissemination, distribution, copying, or action taken in relation to >> the contents of and attachments to this E-mail is strictly prohibited and >> may be unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any copy of >> this E-mail and any printout. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 28 11:50:57 2014 From: jcurran at arin.net (John Curran) Date: Mon, 28 Jul 2014 15:50:57 +0000 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: <2CD0E362-91CF-42A5-AF1B-2E8379D4B165@corp.arin.net> On Jul 28, 2014, at 11:43 AM, Jason Schiller wrote: > Leslie, > > Would it be possible to list the number of Org IDs that hold a given amount of /24 equivalents of ARIN IP space? > > Something like: > > Number of Orgs /24 equ > 60 1 > 30 2 > 49 3 > 100 4 > 22 7 > 432 8 > > I think this may be a useful number in understanding how "incidental" a /20 is. Jason - Are you referring to ISP or end-user address holdings (or both?) Thanks! /John John Curran President and CEO ARIN From jschiller at google.com Mon Jul 28 12:57:42 2014 From: jschiller at google.com (Jason Schiller) Date: Mon, 28 Jul 2014 12:57:42 -0400 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: <2CD0E362-91CF-42A5-AF1B-2E8379D4B165@corp.arin.net> References: <2CD0E362-91CF-42A5-AF1B-2E8379D4B165@corp.arin.net> Message-ID: I believe the policy in question would apply to both end-user and ISPs, so I think both would be valuable. Thanks, __Jason On Mon, Jul 28, 2014 at 11:50 AM, John Curran wrote: > On Jul 28, 2014, at 11:43 AM, Jason Schiller wrote: > > > Leslie, > > > > Would it be possible to list the number of Org IDs that hold a given > amount of /24 equivalents of ARIN IP space? > > > > Something like: > > > > Number of Orgs /24 equ > > 60 1 > > 30 2 > > 49 3 > > 100 4 > > 22 7 > > 432 8 > > > > I think this may be a useful number in understanding how "incidental" a > /20 is. > > Jason - > > Are you referring to ISP or end-user address holdings (or both?) > > Thanks! > /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 hannigan at gmail.com Mon Jul 28 13:51:10 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 28 Jul 2014 13:51:10 -0400 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: <945b27c5793b42e2b408dbda0c2c7e8e@EX13-MBX-13.ad.syr.edu> References: <945b27c5793b42e2b408dbda0c2c7e8e@EX13-MBX-13.ad.syr.edu> Message-ID: On Fri, Jul 25, 2014 at 2:29 AM, Milton L Mueller wrote: [ clip ] > Current policy neither clearly forbids nor clearly permits out of region > use of ARIN registered resources. This has created confusion and > controversy within > the ARIN community for some time. Earlier work on this issue has > restricting > out of region use in various ways. None of these proposals have gained > consensus. The next logical option is to discuss a proposal that clearly > permits > IP numbers are both unique and globally route-able. Why do we need a policy to tell us this? How does inversing the statements (not allowed vs. allowed) in the policy amount to any substantive change? It doesn't. > out of region use. Permitting out of region use, however, poses issues > that have > to be addressed by policy and adjustments to operational practice. Out of > region use must be clearly defined and any operational practices based on > that definition must not be unnecessarily burdensome. Also, it is more > difficult and costly for ARIN staff to independently verify the > justification and utilization of resources that are used outside of the > ARIN service region. There needs to be recognition of this difference in > policy and associated operational practices. > I'm confused. Why is it "more difficult" to verify justifications and utilization "outside" of the ARIN region than in? If I assign an address to an interface in Boston vs. an interface in Hong Kong, the only difference is the geo. ARIN already doesn't understand the vast majority of the geo nomenclature we use whether its in Boston or Hong Kong e.g. 230 Congress vs. 9 Pat Tat, whether it's owned by a REIT (DLR) or is a tenancy (Equinix). > Policy statement: > > Create new Section X; > > X. Out of region use > > ARIN registered resources may be used outside the ARIN service region and > such use is valid justification for new or additional resources. A resource > is considered to be used outside the region if it exclusively serves a > user, customer or technical infrastructure location outside the ARIN > service region. > What does "exclusively" serves a user mean? > > > The services and facilities used to justify the need for ARIN resources > that will be used out of region should not also be used to justify resource > requests from another RIR. > Isn't this meddling in other RIR local policies? If LACNIC says it's ok for one to justify their utilization based on their aggregate RIR history and that's acceptable to LACNIC and the party requesting addresses, why is it not acceptable to ARIN? How is it enforced if both parties simply ignore ARIN (which is what could likely happen)? When a request for resources from ARIN is justified by need located within > another RIR's service region and is more than the equivalent of a /20 for > IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization will > also report to ARIN the utilization status of all resources of the same > type held with any other RIR that are used or are available for use within > the requested service region. > [ Waiting to see the answer to the Schiller question ] > The organization will also supply any additional supporting documentation > requested by ARIN regarding the need for the reported resources. The > report must demonstrate that all resources currently available for use > within the requested service region are efficiently utilized based on > applicable ARIN policy. > If I have LACNIC resources in the LACNIC region and I am meeting the prescribed needs requirements there, but not in the ARIN region, I have to subject myself to a Section 12 audit for my LACNIC derived addresses? This doesn't sound right, or productive. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 28 16:30:53 2014 From: jcurran at arin.net (John Curran) Date: Mon, 28 Jul 2014 20:30:53 +0000 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: On Jul 28, 2014, at 11:43 AM, Jason Schiller wrote: > Would it be possible to list the number of Org IDs that hold a given amount of /24 equivalents of ARIN IP space? > > Something like: > > Number of Orgs /24 equ > 60 1 > 30 2 > 49 3 > 100 4 > 22 7 > 432 8 Jason - Attached. Counts (and time to generate) will be more complicated if we do ISP vs end-user, ARIN-assigned or -prior, so I figured that getting you the data as requested would be a good start. FYI, /John John Curran President and CEO ARIN === Number of Orgs holding given # of /24 equivalents # /24s # Org IDs 1 11503 2 1815 3 435 4 2346 5 314 6 212 7 86 8 1229 9 73 10 123 11 37 12 259 13 36 14 19 15 32 16 1509 17 72 18 34 19 14 20 178 21 15 22 13 23 8 24 124 25 14 26 12 27 5 28 57 29 4 30 23 31 4 32 796 33 42 34 15 35 5 36 72 37 1 38 3 39 1 40 38 41 7 42 3 43 1 44 33 45 1 46 6 47 1 48 210 49 5 50 13 51 3 52 38 53 1 54 1 56 25 57 1 58 1 59 1 60 13 61 1 62 1 64 317 65 12 66 6 68 36 69 5 70 2 71 1 72 27 73 1 74 2 75 2 76 8 78 5 79 1 80 78 81 2 82 1 84 21 85 1 87 1 88 14 89 2 90 1 92 11 94 1 95 2 96 58 97 3 98 3 99 1 100 22 101 3 102 2 104 16 108 2 109 2 111 1 112 41 114 1 116 7 117 3 120 6 124 6 128 117 129 4 130 1 132 11 133 2 136 10 137 1 140 3 141 1 144 35 145 1 148 6 150 1 152 8 153 1 156 4 159 1 160 38 161 3 163 1 164 1 167 1 168 3 171 1 172 3 176 18 177 2 180 6 184 2 188 1 191 1 192 15 193 2 196 2 200 4 204 1 206 1 208 10 209 2 212 3 214 1 215 1 216 5 220 2 224 22 225 1 228 3 230 1 232 4 238 1 240 9 242 1 248 1 252 4 254 1 255 1 256 2092 257 167 258 50 259 21 260 24 261 17 262 9 263 6 264 11 265 6 266 9 267 4 268 5 269 4 271 2 272 25 273 4 274 6 275 1 276 3 278 1 279 1 280 7 281 4 282 1 283 1 284 2 286 2 287 1 288 24 289 2 290 2 292 3 293 1 294 4 295 2 296 4 297 3 299 1 301 1 304 7 306 1 308 1 312 2 316 3 318 1 320 15 321 4 323 1 324 1 328 4 330 1 336 7 338 1 339 1 340 1 342 2 345 1 348 1 352 13 353 1 354 1 356 3 358 1 360 1 364 1 366 1 368 4 376 3 380 1 382 1 384 16 385 2 386 1 388 3 389 1 391 2 392 5 396 1 400 5 401 1 408 2 410 1 412 1 416 5 417 1 421 2 428 2 430 1 432 3 440 1 448 7 451 2 452 3 460 1 464 2 468 1 476 1 480 4 496 2 500 1 504 1 512 125 513 18 514 10 515 8 516 7 517 5 518 2 519 4 520 6 521 1 522 1 523 2 524 2 526 2 527 1 528 8 529 1 530 3 532 2 533 1 535 1 536 1 538 1 544 5 546 1 547 1 548 2 549 1 551 1 552 1 553 1 554 2 556 1 560 2 562 1 576 6 580 1 584 2 586 1 587 2 592 1 600 1 608 4 612 1 624 1 632 1 640 5 642 2 656 2 660 1 672 2 688 2 709 1 712 1 720 1 736 3 740 1 744 1 752 1 760 1 766 2 768 26 769 6 770 4 772 5 774 2 776 1 777 1 781 1 784 2 785 2 786 2 787 1 793 1 794 2 798 1 800 4 804 1 807 1 809 1 816 2 832 2 833 1 840 1 848 1 851 1 857 1 863 1 864 3 866 1 896 1 904 1 910 1 920 1 928 4 935 1 948 1 952 1 962 1 967 1 976 1 992 3 1008 3 1012 1 1016 2 1020 1 1024 19 1026 3 1027 3 1028 2 1031 1 1034 3 1036 1 1038 1 1040 1 1049 1 1050 1 1056 3 1057 1 1080 1 1084 1 1088 2 1096 1 1100 1 1152 2 1155 1 1174 1 1176 1 1184 1 1188 1 1206 1 1211 1 1216 2 1248 1 1250 1 1263 1 1265 1 1276 2 1280 7 1281 3 1282 5 1283 1 1285 1 1286 1 1288 1 1289 1 1293 1 1296 1 1304 1 1312 1 1317 1 1320 1 1359 1 1376 1 1377 1 1380 1 1392 1 1440 1 1456 1 1478 1 1504 1 1520 1 1536 9 1537 1 1538 1 1539 1 1541 1 1543 1 1563 1 1574 1 1576 1 1616 1 1626 1 1633 2 1664 2 1704 1 1730 1 1748 1 1792 1 1796 1 1797 1 1808 2 1824 1 1829 1 1848 1 1873 1 1952 1 1992 1 2016 2 2048 3 2050 1 2051 1 2052 1 2054 1 2058 1 2064 1 2068 1 2072 1 2112 2 2124 1 2176 1 2208 1 2276 1 2304 1 2305 2 2309 1 2311 1 2340 1 2358 1 2368 1 2372 1 2432 2 2465 1 2561 1 2572 1 2576 1 2624 1 2688 1 2712 1 2752 1 2800 1 2816 1 2852 1 2928 1 3008 1 3072 2 3073 1 3095 1 3104 2 3232 1 3328 1 3352 1 3358 1 3372 1 3462 1 3532 1 3552 1 3584 1 3600 1 3603 1 3608 1 3683 2 3735 1 3755 1 3808 1 3840 1 3863 1 3919 1 3936 1 3953 1 3968 2 4064 1 4096 1 4178 1 4192 2 4197 1 4208 1 4304 1 4352 1 4362 1 4368 1 4375 1 4384 1 4611 1 4672 1 4673 1 4680 1 4724 1 4771 1 4824 1 5080 1 5087 1 5117 1 5120 2 5130 1 5377 1 5888 1 5984 1 6144 4 6148 1 6232 1 6383 1 6400 2 6432 1 6481 1 6531 1 6784 1 6921 1 6984 1 7168 1 7171 1 8091 1 8096 1 8640 1 8704 2 8960 1 9344 1 11104 1 11265 1 11416 1 12544 1 12803 1 12840 1 13200 1 13440 1 13580 1 14059 1 14400 1 15448 1 16604 1 18065 1 18101 1 18433 1 20224 1 21312 1 21570 1 21792 1 23084 1 23232 1 23712 1 23976 1 24064 1 24321 1 25906 1 26168 1 31664 1 32256 1 32864 1 33280 1 34817 1 34870 1 35844 1 42336 1 45024 1 45832 1 46176 1 47593 1 48454 1 48544 1 49568 1 56662 1 58624 1 58625 1 59374 1 61441 1 63813 1 65536 6 65537 1 65538 1 65792 1 66071 1 66089 1 66306 1 67092 1 68177 1 69632 1 70308 1 73216 1 73264 1 75027 1 91280 1 98560 1 101966 1 109542 1 156461 1 177065 1 214023 1 219751 1 862247 1 From scottleibrand at gmail.com Mon Jul 28 16:57:08 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 28 Jul 2014 13:57:08 -0700 Subject: [arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use) In-Reply-To: References: Message-ID: To save everyone else the trouble, here's some simple spreadsheet calculations on this data. It looks like all ARIN allocations to orgs holding /20 and smaller (longer) add up to 1.07 /8 equivalents, or approximately 1% of ARIN-managed resources. The .xlsx is also attached: hopefully Numbers didn't munge it too badly. -Scott # /24s # Org IDs CIDR equivalent Total /24s at this size Cumulative /8 equivalents 1 11503 /24 11503 0.18 2 1815 /23 3630 0.23 3 435 1305 0.25 4 2346 /22 9384 0.39 5 314 1570 0.42 6 212 1272 0.44 7 86 602 0.45 8 1229 /21 9832 0.60 9 73 657 0.61 10 123 1230 0.63 11 37 407 0.63 12 259 3108 0.68 13 36 468 0.69 14 19 266 0.69 15 32 480 0.70 16 1509 /20 24144 1.07 17 72 1224 1.08 18 34 612 1.09 19 14 266 1.10 20 178 3560 1.15 21 15 315 1.16 22 13 286 1.16 23 8 184 1.16 24 124 2976 1.21 25 14 350 1.22 26 12 312 1.22 27 5 135 1.22 28 57 1596 1.25 29 4 116 1.25 30 23 690 1.26 31 4 124 1.26 32 796 /19 25472 1.65 33 42 1386 1.67 34 15 510 1.68 35 5 175 1.68 36 72 2592 1.72 37 1 37 1.72 38 3 114 1.72 39 1 39 1.72 40 38 1520 1.75 41 7 287 1.75 42 3 126 1.75 43 1 43 1.75 44 33 1452 1.78 45 1 45 1.78 46 6 276 1.78 47 1 47 1.78 48 210 10080 1.93 49 5 245 1.94 50 13 650 1.95 51 3 153 1.95 52 38 1976 1.98 53 1 53 1.98 54 1 54 1.98 56 25 1400 2.00 57 1 57 2.00 58 1 58 2.01 59 1 59 2.01 60 13 780 2.02 61 1 61 2.02 62 1 62 2.02 64 317 /18 20288 2.33 65 12 780 2.34 66 6 396 2.35 68 36 2448 2.39 69 5 345 2.39 70 2 140 2.39 71 1 71 2.39 72 27 1944 2.42 73 1 73 2.42 74 2 148 2.43 75 2 150 2.43 76 8 608 2.44 78 5 390 2.44 79 1 79 2.45 80 78 6240 2.54 81 2 162 2.54 82 1 82 2.54 84 21 1764 2.57 85 1 85 2.57 87 1 87 2.57 88 14 1232 2.59 89 2 178 2.60 90 1 90 2.60 92 11 1012 2.61 94 1 94 2.61 95 2 190 2.62 96 58 5568 2.70 97 3 291 2.71 98 3 294 2.71 99 1 99 2.71 100 22 2200 2.75 101 3 303 2.75 102 2 204 2.75 104 16 1664 2.78 108 2 216 2.78 109 2 218 2.79 111 1 111 2.79 112 41 4592 2.86 114 1 114 2.86 116 7 812 2.87 117 3 351 2.88 120 6 720 2.89 124 6 744 2.90 128 117 /17 14976 3.13 129 4 516 3.14 130 1 130 3.14 132 11 1452 3.16 133 2 266 3.16 136 10 1360 3.18 137 1 137 3.19 140 3 420 3.19 141 1 141 3.20 144 35 5040 3.27 145 1 145 3.27 148 6 888 3.29 150 1 150 3.29 152 8 1216 3.31 153 1 153 3.31 156 4 624 3.32 159 1 159 3.32 160 38 6080 3.42 161 3 483 3.42 163 1 163 3.43 164 1 164 3.43 167 1 167 3.43 168 3 504 3.44 171 1 171 3.44 172 3 516 3.45 176 18 3168 3.50 177 2 354 3.50 180 6 1080 3.52 184 2 368 3.52 188 1 188 3.53 191 1 191 3.53 192 15 2880 3.57 193 2 386 3.58 196 2 392 3.59 200 4 800 3.60 204 1 204 3.60 206 1 206 3.60 208 10 2080 3.64 209 2 418 3.64 212 3 636 3.65 214 1 214 3.66 215 1 215 3.66 216 5 1080 3.68 220 2 440 3.68 224 22 4928 3.76 225 1 225 3.76 228 3 684 3.77 230 1 230 3.77 232 4 928 3.79 238 1 238 3.79 240 9 2160 3.83 242 1 242 3.83 248 1 248 3.83 252 4 1008 3.85 254 1 254 3.85 255 1 255 3.86 256 2092 /16 535552 12.03 257 167 42919 12.68 258 50 12900 12.88 259 21 5439 12.96 260 24 6240 13.06 261 17 4437 13.13 262 9 2358 13.16 263 6 1578 13.19 264 11 2904 13.23 265 6 1590 13.25 266 9 2394 13.29 267 4 1068 13.31 268 5 1340 13.33 269 4 1076 13.34 271 2 542 13.35 272 25 6800 13.46 273 4 1092 13.47 274 6 1644 13.50 275 1 275 13.50 276 3 828 13.51 278 1 278 13.52 279 1 279 13.52 280 7 1960 13.55 281 4 1124 13.57 282 1 282 13.57 283 1 283 13.58 284 2 568 13.59 286 2 572 13.60 287 1 287 13.60 288 24 6912 13.71 289 2 578 13.71 290 2 580 13.72 292 3 876 13.74 293 1 293 13.74 294 4 1176 13.76 295 2 590 13.77 296 4 1184 13.79 297 3 891 13.80 299 1 299 13.80 301 1 301 13.81 304 7 2128 13.84 306 1 306 13.85 308 1 308 13.85 312 2 624 13.86 316 3 948 13.88 318 1 318 13.88 320 15 4800 13.95 321 4 1284 13.97 323 1 323 13.98 324 1 324 13.98 328 4 1312 14.00 330 1 330 14.01 336 7 2352 14.04 338 1 338 14.05 339 1 339 14.05 340 1 340 14.06 342 2 684 14.07 345 1 345 14.07 348 1 348 14.08 352 13 4576 14.15 353 1 353 14.16 354 1 354 14.16 356 3 1068 14.18 358 1 358 14.18 360 1 360 14.19 364 1 364 14.19 366 1 366 14.20 368 4 1472 14.22 376 3 1128 14.24 380 1 380 14.24 382 1 382 14.25 384 16 6144 14.34 385 2 770 14.36 386 1 386 14.36 388 3 1164 14.38 389 1 389 14.39 391 2 782 14.40 392 5 1960 14.43 396 1 396 14.43 400 5 2000 14.46 401 1 401 14.47 408 2 816 14.48 410 1 410 14.49 412 1 412 14.49 416 5 2080 14.53 417 1 417 14.53 421 2 842 14.55 428 2 856 14.56 430 1 430 14.57 432 3 1296 14.59 440 1 440 14.59 448 7 3136 14.64 451 2 902 14.65 452 3 1356 14.67 460 1 460 14.68 464 2 928 14.70 468 1 468 14.70 476 1 476 14.71 480 4 1920 14.74 496 2 992 14.75 500 1 500 14.76 504 1 504 14.77 512 125 /15 64000 15.75 513 18 9234 15.89 514 10 5140 15.97 515 8 4120 16.03 516 7 3612 16.08 517 5 2585 16.12 518 2 1036 16.14 519 4 2076 16.17 520 6 3120 16.22 521 1 521 16.23 522 1 522 16.23 523 2 1046 16.25 524 2 1048 16.27 526 2 1052 16.28 527 1 527 16.29 528 8 4224 16.35 529 1 529 16.36 530 3 1590 16.39 532 2 1064 16.40 533 1 533 16.41 535 1 535 16.42 536 1 536 16.43 538 1 538 16.44 544 5 2720 16.48 546 1 546 16.49 547 1 547 16.49 548 2 1096 16.51 549 1 549 16.52 551 1 551 16.53 552 1 552 16.54 553 1 553 16.54 554 2 1108 16.56 556 1 556 16.57 560 2 1120 16.59 562 1 562 16.60 576 6 3456 16.65 580 1 580 16.66 584 2 1168 16.67 586 1 586 16.68 587 2 1174 16.70 592 1 592 16.71 600 1 600 16.72 608 4 2432 16.76 612 1 612 16.77 624 1 624 16.78 632 1 632 16.79 640 5 3200 16.83 642 2 1284 16.85 656 2 1312 16.87 660 1 660 16.88 672 2 1344 16.90 688 2 1376 16.93 709 1 709 16.94 712 1 712 16.95 720 1 720 16.96 736 3 2208 16.99 740 1 740 17.00 744 1 744 17.01 752 1 752 17.03 760 1 760 17.04 766 2 1532 17.06 768 26 19968 17.37 769 6 4614 17.44 770 4 3080 17.48 772 5 3860 17.54 774 2 1548 17.57 776 1 776 17.58 777 1 777 17.59 781 1 781 17.60 784 2 1568 17.63 785 2 1570 17.65 786 2 1572 17.67 787 1 787 17.68 793 1 793 17.70 794 2 1588 17.72 798 1 798 17.73 800 4 3200 17.78 804 1 804 17.79 807 1 807 17.81 809 1 809 17.82 816 2 1632 17.84 832 2 1664 17.87 833 1 833 17.88 840 1 840 17.90 848 1 848 17.91 851 1 851 17.92 857 1 857 17.93 863 1 863 17.95 864 3 2592 17.99 866 1 866 18.00 896 1 896 18.01 904 1 904 18.03 910 1 910 18.04 920 1 920 18.06 928 4 3712 18.11 935 1 935 18.13 948 1 948 18.14 952 1 952 18.16 962 1 962 18.17 967 1 967 18.18 976 1 976 18.20 992 3 2976 18.25 1008 3 3024 18.29 1012 1 1012 18.31 1016 2 2032 18.34 1020 1 1020 18.35 1024 19 /14 19456 18.65 1026 3 3078 18.70 1027 3 3081 18.74 1028 2 2056 18.78 1031 1 1031 18.79 1034 3 3102 18.84 1036 1 1036 18.85 1038 1 1038 18.87 1040 1 1040 18.89 1049 1 1049 18.90 1050 1 1050 18.92 1056 3 3168 18.97 1057 1 1057 18.98 1080 1 1080 19.00 1084 1 1084 19.02 1088 2 2176 19.05 1096 1 1096 19.07 1100 1 1100 19.08 1152 2 2304 19.12 1155 1 1155 19.13 1174 1 1174 19.15 1176 1 1176 19.17 1184 1 1184 19.19 1188 1 1188 19.21 1206 1 1206 19.23 1211 1 1211 19.24 1216 2 2432 19.28 1248 1 1248 19.30 1250 1 1250 19.32 1263 1 1263 19.34 1265 1 1265 19.36 1276 2 2552 19.40 1280 7 8960 19.53 1281 3 3843 19.59 1282 5 6410 19.69 1283 1 1283 19.71 1285 1 1285 19.73 1286 1 1286 19.75 1288 1 1288 19.77 1289 1 1289 19.79 1293 1 1293 19.81 1296 1 1296 19.83 1304 1 1304 19.85 1312 1 1312 19.87 1317 1 1317 19.89 1320 1 1320 19.91 1359 1 1359 19.93 1376 1 1376 19.95 1377 1 1377 19.97 1380 1 1380 19.99 1392 1 1392 20.01 1440 1 1440 20.03 1456 1 1456 20.06 1478 1 1478 20.08 1504 1 1504 20.10 1520 1 1520 20.13 1536 9 13824 20.34 1537 1 1537 20.36 1538 1 1538 20.38 1539 1 1539 20.41 1541 1 1541 20.43 1543 1 1543 20.45 1563 1 1563 20.48 1574 1 1574 20.50 1576 1 1576 20.53 1616 1 1616 20.55 1626 1 1626 20.58 1633 2 3266 20.63 1664 2 3328 20.68 1704 1 1704 20.70 1730 1 1730 20.73 1748 1 1748 20.76 1792 1 1792 20.78 1796 1 1796 20.81 1797 1 1797 20.84 1808 2 3616 20.89 1824 1 1824 20.92 1829 1 1829 20.95 1848 1 1848 20.98 1873 1 1873 21.00 1952 1 1952 21.03 1992 1 1992 21.07 2016 2 4032 21.13 2048 3 /13 6144 21.22 2050 1 2050 21.25 2051 1 2051 21.28 2052 1 2052 21.31 2054 1 2054 21.35 2058 1 2058 21.38 2064 1 2064 21.41 2068 1 2068 21.44 2072 1 2072 21.47 2112 2 4224 21.54 2124 1 2124 21.57 2176 1 2176 21.60 2208 1 2208 21.64 2276 1 2276 21.67 2304 1 2304 21.71 2305 2 4610 21.78 2309 1 2309 21.81 2311 1 2311 21.85 2340 1 2340 21.88 2358 1 2358 21.92 2368 1 2368 21.95 2372 1 2372 21.99 2432 2 4864 22.06 2465 1 2465 22.10 2561 1 2561 22.14 2572 1 2572 22.18 2576 1 2576 22.22 2624 1 2624 22.26 2688 1 2688 22.30 2712 1 2712 22.34 2752 1 2752 22.38 2800 1 2800 22.43 2816 1 2816 22.47 2852 1 2852 22.51 2928 1 2928 22.56 3008 1 3008 22.60 3072 2 6144 22.70 3073 1 3073 22.74 3095 1 3095 22.79 3104 2 6208 22.89 3232 1 3232 22.94 3328 1 3328 22.99 3352 1 3352 23.04 3358 1 3358 23.09 3372 1 3372 23.14 3462 1 3462 23.19 3532 1 3532 23.25 3552 1 3552 23.30 3584 1 3584 23.36 3600 1 3600 23.41 3603 1 3603 23.47 3608 1 3608 23.52 3683 2 7366 23.63 3735 1 3735 23.69 3755 1 3755 23.75 3808 1 3808 23.81 3840 1 3840 23.86 3863 1 3863 23.92 3919 1 3919 23.98 3936 1 3936 24.04 3953 1 3953 24.10 3968 2 7936 24.22 4064 1 4064 24.29 4096 1 /12 4096 24.35 4178 1 4178 24.41 4192 2 8384 24.54 4197 1 4197 24.60 4208 1 4208 24.67 4304 1 4304 24.73 4352 1 4352 24.80 4362 1 4362 24.87 4368 1 4368 24.93 4375 1 4375 25.00 4384 1 4384 25.07 4611 1 4611 25.14 4672 1 4672 25.21 4673 1 4673 25.28 4680 1 4680 25.35 4724 1 4724 25.42 4771 1 4771 25.50 4824 1 4824 25.57 5080 1 5080 25.65 5087 1 5087 25.73 5117 1 5117 25.80 5120 2 10240 25.96 5130 1 5130 26.04 5377 1 5377 26.12 5888 1 5888 26.21 5984 1 5984 26.30 6144 4 24576 26.68 6148 1 6148 26.77 6232 1 6232 26.87 6383 1 6383 26.96 6400 2 12800 27.16 6432 1 6432 27.26 6481 1 6481 27.36 6531 1 6531 27.45 6784 1 6784 27.56 6921 1 6921 27.66 6984 1 6984 27.77 7168 1 7168 27.88 7171 1 7171 27.99 8091 1 8091 28.11 8096 1 8096 28.24 8640 1 8640 28.37 8704 2 17408 28.63 8960 1 8960 28.77 9344 1 9344 28.91 11104 1 11104 29.08 11265 1 11265 29.25 11416 1 11416 29.43 12544 1 12544 29.62 12803 1 12803 29.82 12840 1 12840 30.01 13200 1 13200 30.21 13440 1 13440 30.42 13580 1 13580 30.63 14059 1 14059 30.84 14400 1 14400 31.06 15448 1 15448 31.30 16604 1 16604 31.55 18065 1 18065 31.82 18101 1 18101 32.10 18433 1 18433 32.38 20224 1 20224 32.69 21312 1 21312 33.02 21570 1 21570 33.34 21792 1 21792 33.68 23084 1 23084 34.03 23232 1 23232 34.38 23712 1 23712 34.75 23976 1 23976 35.11 24064 1 24064 35.48 24321 1 24321 35.85 25906 1 25906 36.24 26168 1 26168 36.64 31664 1 31664 37.13 32256 1 32256 37.62 32864 1 32864 38.12 33280 1 33280 38.63 34817 1 34817 39.16 34870 1 34870 39.69 35844 1 35844 40.24 42336 1 42336 40.89 45024 1 45024 41.57 45832 1 45832 42.27 46176 1 46176 42.98 47593 1 47593 43.70 48454 1 48454 44.44 48544 1 48544 45.18 49568 1 49568 45.94 56662 1 56662 46.80 58624 1 58624 47.70 58625 1 58625 48.59 59374 1 59374 49.50 61441 1 61441 50.44 63813 1 63813 51.41 65536 6 /8 393216 57.41 65537 1 65537 58.41 65538 1 65538 59.41 65792 1 65792 60.41 66071 1 66071 61.42 66089 1 66089 62.43 66306 1 66306 63.44 67092 1 67092 64.47 68177 1 68177 65.51 69632 1 69632 66.57 70308 1 70308 67.64 73216 1 73216 68.76 73264 1 73264 69.88 75027 1 75027 71.02 91280 1 91280 72.41 98560 1 98560 73.92 101966 1 101966 75.47 109542 1 109542 77.15 156461 1 156461 79.53 177065 1 177065 82.23 214023 1 214023 85.50 219751 1 219751 88.85 862247 1 862247 102.01 On Mon, Jul 28, 2014 at 1:30 PM, John Curran wrote: > On Jul 28, 2014, at 11:43 AM, Jason Schiller wrote: > > Would it be possible to list the number of Org IDs that hold a given > amount of /24 equivalents of ARIN IP space? > > > > Something like: > > > > Number of Orgs /24 equ > > 60 1 > > 30 2 > > 49 3 > > 100 4 > > 22 7 > > 432 8 > > Jason - > > Attached. Counts (and time to generate) will be more complicated if > we do ISP vs > end-user, ARIN-assigned or -prior, so I figured that getting you the > data as requested > would be a good start. > > FYI, > /John > > John Curran > President and CEO > ARIN > > === Number of Orgs holding given # of /24 equivalents > > # /24s # Org IDs > 1 11503 > 2 1815 > 3 435 > 4 2346 > 5 314 > 6 212 > 7 86 > 8 1229 > 9 73 > 10 123 > 11 37 > 12 259 > 13 36 > 14 19 > 15 32 > 16 1509 > 17 72 > 18 34 > 19 14 > 20 178 > 21 15 > 22 13 > 23 8 > 24 124 > 25 14 > 26 12 > 27 5 > 28 57 > 29 4 > 30 23 > 31 4 > 32 796 > 33 42 > 34 15 > 35 5 > 36 72 > 37 1 > 38 3 > 39 1 > 40 38 > 41 7 > 42 3 > 43 1 > 44 33 > 45 1 > 46 6 > 47 1 > 48 210 > 49 5 > 50 13 > 51 3 > 52 38 > 53 1 > 54 1 > 56 25 > 57 1 > 58 1 > 59 1 > 60 13 > 61 1 > 62 1 > 64 317 > 65 12 > 66 6 > 68 36 > 69 5 > 70 2 > 71 1 > 72 27 > 73 1 > 74 2 > 75 2 > 76 8 > 78 5 > 79 1 > 80 78 > 81 2 > 82 1 > 84 21 > 85 1 > 87 1 > 88 14 > 89 2 > 90 1 > 92 11 > 94 1 > 95 2 > 96 58 > 97 3 > 98 3 > 99 1 > 100 22 > 101 3 > 102 2 > 104 16 > 108 2 > 109 2 > 111 1 > 112 41 > 114 1 > 116 7 > 117 3 > 120 6 > 124 6 > 128 117 > 129 4 > 130 1 > 132 11 > 133 2 > 136 10 > 137 1 > 140 3 > 141 1 > 144 35 > 145 1 > 148 6 > 150 1 > 152 8 > 153 1 > 156 4 > 159 1 > 160 38 > 161 3 > 163 1 > 164 1 > 167 1 > 168 3 > 171 1 > 172 3 > 176 18 > 177 2 > 180 6 > 184 2 > 188 1 > 191 1 > 192 15 > 193 2 > 196 2 > 200 4 > 204 1 > 206 1 > 208 10 > 209 2 > 212 3 > 214 1 > 215 1 > 216 5 > 220 2 > 224 22 > 225 1 > 228 3 > 230 1 > 232 4 > 238 1 > 240 9 > 242 1 > 248 1 > 252 4 > 254 1 > 255 1 > 256 2092 > 257 167 > 258 50 > 259 21 > 260 24 > 261 17 > 262 9 > 263 6 > 264 11 > 265 6 > 266 9 > 267 4 > 268 5 > 269 4 > 271 2 > 272 25 > 273 4 > 274 6 > 275 1 > 276 3 > 278 1 > 279 1 > 280 7 > 281 4 > 282 1 > 283 1 > 284 2 > 286 2 > 287 1 > 288 24 > 289 2 > 290 2 > 292 3 > 293 1 > 294 4 > 295 2 > 296 4 > 297 3 > 299 1 > 301 1 > 304 7 > 306 1 > 308 1 > 312 2 > 316 3 > 318 1 > 320 15 > 321 4 > 323 1 > 324 1 > 328 4 > 330 1 > 336 7 > 338 1 > 339 1 > 340 1 > 342 2 > 345 1 > 348 1 > 352 13 > 353 1 > 354 1 > 356 3 > 358 1 > 360 1 > 364 1 > 366 1 > 368 4 > 376 3 > 380 1 > 382 1 > 384 16 > 385 2 > 386 1 > 388 3 > 389 1 > 391 2 > 392 5 > 396 1 > 400 5 > 401 1 > 408 2 > 410 1 > 412 1 > 416 5 > 417 1 > 421 2 > 428 2 > 430 1 > 432 3 > 440 1 > 448 7 > 451 2 > 452 3 > 460 1 > 464 2 > 468 1 > 476 1 > 480 4 > 496 2 > 500 1 > 504 1 > 512 125 > 513 18 > 514 10 > 515 8 > 516 7 > 517 5 > 518 2 > 519 4 > 520 6 > 521 1 > 522 1 > 523 2 > 524 2 > 526 2 > 527 1 > 528 8 > 529 1 > 530 3 > 532 2 > 533 1 > 535 1 > 536 1 > 538 1 > 544 5 > 546 1 > 547 1 > 548 2 > 549 1 > 551 1 > 552 1 > 553 1 > 554 2 > 556 1 > 560 2 > 562 1 > 576 6 > 580 1 > 584 2 > 586 1 > 587 2 > 592 1 > 600 1 > 608 4 > 612 1 > 624 1 > 632 1 > 640 5 > 642 2 > 656 2 > 660 1 > 672 2 > 688 2 > 709 1 > 712 1 > 720 1 > 736 3 > 740 1 > 744 1 > 752 1 > 760 1 > 766 2 > 768 26 > 769 6 > 770 4 > 772 5 > 774 2 > 776 1 > 777 1 > 781 1 > 784 2 > 785 2 > 786 2 > 787 1 > 793 1 > 794 2 > 798 1 > 800 4 > 804 1 > 807 1 > 809 1 > 816 2 > 832 2 > 833 1 > 840 1 > 848 1 > 851 1 > 857 1 > 863 1 > 864 3 > 866 1 > 896 1 > 904 1 > 910 1 > 920 1 > 928 4 > 935 1 > 948 1 > 952 1 > 962 1 > 967 1 > 976 1 > 992 3 > 1008 3 > 1012 1 > 1016 2 > 1020 1 > 1024 19 > 1026 3 > 1027 3 > 1028 2 > 1031 1 > 1034 3 > 1036 1 > 1038 1 > 1040 1 > 1049 1 > 1050 1 > 1056 3 > 1057 1 > 1080 1 > 1084 1 > 1088 2 > 1096 1 > 1100 1 > 1152 2 > 1155 1 > 1174 1 > 1176 1 > 1184 1 > 1188 1 > 1206 1 > 1211 1 > 1216 2 > 1248 1 > 1250 1 > 1263 1 > 1265 1 > 1276 2 > 1280 7 > 1281 3 > 1282 5 > 1283 1 > 1285 1 > 1286 1 > 1288 1 > 1289 1 > 1293 1 > 1296 1 > 1304 1 > 1312 1 > 1317 1 > 1320 1 > 1359 1 > 1376 1 > 1377 1 > 1380 1 > 1392 1 > 1440 1 > 1456 1 > 1478 1 > 1504 1 > 1520 1 > 1536 9 > 1537 1 > 1538 1 > 1539 1 > 1541 1 > 1543 1 > 1563 1 > 1574 1 > 1576 1 > 1616 1 > 1626 1 > 1633 2 > 1664 2 > 1704 1 > 1730 1 > 1748 1 > 1792 1 > 1796 1 > 1797 1 > 1808 2 > 1824 1 > 1829 1 > 1848 1 > 1873 1 > 1952 1 > 1992 1 > 2016 2 > 2048 3 > 2050 1 > 2051 1 > 2052 1 > 2054 1 > 2058 1 > 2064 1 > 2068 1 > 2072 1 > 2112 2 > 2124 1 > 2176 1 > 2208 1 > 2276 1 > 2304 1 > 2305 2 > 2309 1 > 2311 1 > 2340 1 > 2358 1 > 2368 1 > 2372 1 > 2432 2 > 2465 1 > 2561 1 > 2572 1 > 2576 1 > 2624 1 > 2688 1 > 2712 1 > 2752 1 > 2800 1 > 2816 1 > 2852 1 > 2928 1 > 3008 1 > 3072 2 > 3073 1 > 3095 1 > 3104 2 > 3232 1 > 3328 1 > 3352 1 > 3358 1 > 3372 1 > 3462 1 > 3532 1 > 3552 1 > 3584 1 > 3600 1 > 3603 1 > 3608 1 > 3683 2 > 3735 1 > 3755 1 > 3808 1 > 3840 1 > 3863 1 > 3919 1 > 3936 1 > 3953 1 > 3968 2 > 4064 1 > 4096 1 > 4178 1 > 4192 2 > 4197 1 > 4208 1 > 4304 1 > 4352 1 > 4362 1 > 4368 1 > 4375 1 > 4384 1 > 4611 1 > 4672 1 > 4673 1 > 4680 1 > 4724 1 > 4771 1 > 4824 1 > 5080 1 > 5087 1 > 5117 1 > 5120 2 > 5130 1 > 5377 1 > 5888 1 > 5984 1 > 6144 4 > 6148 1 > 6232 1 > 6383 1 > 6400 2 > 6432 1 > 6481 1 > 6531 1 > 6784 1 > 6921 1 > 6984 1 > 7168 1 > 7171 1 > 8091 1 > 8096 1 > 8640 1 > 8704 2 > 8960 1 > 9344 1 > 11104 1 > 11265 1 > 11416 1 > 12544 1 > 12803 1 > 12840 1 > 13200 1 > 13440 1 > 13580 1 > 14059 1 > 14400 1 > 15448 1 > 16604 1 > 18065 1 > 18101 1 > 18433 1 > 20224 1 > 21312 1 > 21570 1 > 21792 1 > 23084 1 > 23232 1 > 23712 1 > 23976 1 > 24064 1 > 24321 1 > 25906 1 > 26168 1 > 31664 1 > 32256 1 > 32864 1 > 33280 1 > 34817 1 > 34870 1 > 35844 1 > 42336 1 > 45024 1 > 45832 1 > 46176 1 > 47593 1 > 48454 1 > 48544 1 > 49568 1 > 56662 1 > 58624 1 > 58625 1 > 59374 1 > 61441 1 > 63813 1 > 65536 6 > 65537 1 > 65538 1 > 65792 1 > 66071 1 > 66089 1 > 66306 1 > 67092 1 > 68177 1 > 69632 1 > 70308 1 > 73216 1 > 73264 1 > 75027 1 > 91280 1 > 98560 1 > 101966 1 > 109542 1 > 156461 1 > 177065 1 > 214023 1 > 219751 1 > 862247 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Resources by size.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 526106 bytes Desc: not available URL: From info at arin.net Mon Jul 28 17:26:41 2014 From: info at arin.net (ARIN) Date: Mon, 28 Jul 2014 17:26:41 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers - revised Message-ID: <53D6C011.8040500@arin.net> Draft Policy ARIN-2014-15 Allow Inter-RIR ASN Transfers ARIN-2014-15 has been revised. Draft Policy ARIN-2014-15 is below and can be found at: https://www.arin.net/policy/proposals/2014_15.html We are also attaching a staff assessment. You are encouraged to discuss the merits and your concerns of Draft Policy 2014-15 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-2014-15 Allow Inter-RIR ASN Transfers Revised: 19 June 2014 Problem Statement: We already allow transfer of ASNs within the ARIN region. Recently APNIC implemented a policy allowing for Inter-regional ASN transfers to RIRs with reciprocal policies. This change in language would allow for ASN transfers to and from the APNIC region. Policy Statement: Add "or ASNs to be transferred, as" to the first bullet point under Conditions on source of the transfer, so that it reads: "The source entity must be the current rights holder of the IPv4 address resources or ASNs to be transferred, as recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources." Change "IPv4 number resources" to "that same resource type (IPv4 number resources or ASNs)", so that the fourth bullet point reads: "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of that same resource type (IPv4 number resources or ASNs) from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers." Timetable for implementation: Immediate ########## ARIN Staff and Legal Assessment Proposal: ARIN-2014-15: Allow Inter-RIR ASN Transfers Date of Assessment: 1 July 2014 1. Summary (Staff Understanding) This proposal would: ? allow inter-RIR transfer of AS numbers ? enforce the 12 month waiting period only on resources of the same type exempt resources received via M&A transfer 2. Comments A. ARIN Staff Comments The impact of inter-RIR transfers of ASNs on ARIN from both an operational and development perspective are nominal today, but pose an unknown (but at least moderate) impact over the medium-term due to potentially significant impacts for additional requirements and/or specifications necessary for RPKI support of inter-RIR ASN transfers. B. ARIN General Counsel - Legal Assessment "The only material legal risk relates to the RPKI issue and policy consideration can take place as continued work by the management and staff of ARIN may be able to fully address this concern before the community considers the policy matter in Baltimore." 3. Resource Impact This policy would have minimal to moderate resource impact from an implementation aspect. It is estimated that implementation would occur within 3 - 9 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Future impact from RPKI implementation could involve either some kind of RIR<->IANA<->RIR coordination system or ERX for ASNs Updated guidelines and internal procedures Staff training 4. Proposal/Draft Policy Text Assessed Draft Policy ARIN-2014-15 Allow Inter-RIR ASN Transfers Revised: 19 June 2014 Problem Statement: We already allow transfer of ASNs within the ARIN region. Recently APNIC implemented a policy allowing for Inter-regional ASN transfers to RIRs with reciprocal policies. This change in language would allow for ASN transfers to and from the APNIC region. Policy Statement: Add "or ASNs to be transferred, as" to the first bullet point under Conditions on source of the transfer, so that it reads: "The source entity must be the current rights holder of the IPv4 address resources or ASNs to be transferred, as recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources." Change "IPv4 number resources" to "that same resource type (IPv4 number resources or ASNs)", so that the fourth bullet point reads: "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of that same resource type (IPv4 number resources or ASNs) from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers." Timetable for implementation: Immediate From scottleibrand at gmail.com Mon Jul 28 17:31:32 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 28 Jul 2014 14:31:32 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers - revised In-Reply-To: <53D6C011.8040500@arin.net> References: <53D6C011.8040500@arin.net> Message-ID: For context, this revision just brings the policy in line with what was discussed at the PPC, addressing a concern raised with the previous iteration of this policy (that transferring ASN resources should not block receipt of IPv4 resources, or vice versa). -Scott On Mon, Jul 28, 2014 at 2:26 PM, ARIN wrote: > Draft Policy ARIN-2014-15 > Allow Inter-RIR ASN Transfers > > ARIN-2014-15 has been revised. > > Draft Policy ARIN-2014-15 is below and can be found at: > https://www.arin.net/policy/proposals/2014_15.html > > We are also attaching a staff assessment. > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2014-15 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-2014-15 > Allow Inter-RIR ASN Transfers > > Revised: 19 June 2014 > > Problem Statement: > > We already allow transfer of ASNs within the ARIN region. Recently APNIC > implemented a policy allowing for Inter-regional ASN transfers to RIRs with > reciprocal policies. This change in language would allow for ASN transfers > to and from the APNIC region. > > Policy Statement: > > Add "or ASNs to be transferred, as" to the first bullet point under > Conditions on source of the transfer, so that it reads: "The source entity > must be the current rights holder of the IPv4 address resources or ASNs to > be transferred, as recognized by the RIR responsible for the resources, and > not be involved in any dispute as to the status of those resources." > > Change "IPv4 number resources" to "that same resource type (IPv4 number > resources or ASNs)", so that the fourth bullet point reads: "Source > entities within the ARIN region must not have received a transfer, > allocation, or assignment of that same resource type (IPv4 number resources > or ASNs) from ARIN for the 12 months prior to the approval of a transfer > request. This restriction does not include M&A transfers." > > Timetable for implementation: Immediate > > ########## > > ARIN Staff and Legal Assessment > > Proposal: ARIN-2014-15: Allow Inter-RIR ASN Transfers > > Date of Assessment: 1 July 2014 > > 1. Summary (Staff Understanding) > > This proposal would: > ? allow inter-RIR transfer of AS numbers > ? enforce the 12 month waiting period only on resources of the same type > exempt resources received via M&A transfer > > 2. Comments > > A. ARIN Staff Comments > > The impact of inter-RIR transfers of ASNs on ARIN from both an operational > and development perspective are nominal today, but pose an unknown (but at > least moderate) impact over the medium-term due to potentially significant > impacts for additional requirements and/or specifications necessary for > RPKI support of inter-RIR ASN transfers. > > B. ARIN General Counsel - Legal Assessment > > "The only material legal risk relates to the RPKI issue and policy > consideration can take place as continued work by the management and staff > of ARIN may be able to fully address this concern before the community > considers the policy matter in Baltimore." > > 3. Resource Impact > > This policy would have minimal to moderate resource impact from an > implementation aspect. It is estimated that implementation would occur > within 3 - 9 months after ratification by the ARIN Board of Trustees. The > following would be needed in order to implement: > > Future impact from RPKI implementation could involve either some kind of > RIR<->IANA<->RIR coordination system or ERX for ASNs > Updated guidelines and internal procedures > Staff training > > 4. Proposal/Draft Policy Text Assessed > > Draft Policy ARIN-2014-15 Allow Inter-RIR ASN Transfers > Revised: 19 June 2014 > > Problem Statement: > We already allow transfer of ASNs within the ARIN region. Recently APNIC > implemented a policy allowing for Inter-regional ASN transfers to RIRs with > reciprocal policies. This change in language would allow for ASN transfers > to and from the APNIC region. > > Policy Statement: > Add "or ASNs to be transferred, as" to the first bullet point under > Conditions on source of the transfer, so that it reads: "The source entity > must be the current rights holder of the IPv4 address resources or ASNs to > be transferred, as recognized by the RIR responsible for the resources, and > not be involved in any dispute as to the status of those resources." Change > "IPv4 number resources" to "that same resource type (IPv4 number resources > or ASNs)", so that the fourth bullet point reads: "Source entities within > the ARIN region must not have received a transfer, allocation, or > assignment of that same resource type (IPv4 number resources or ASNs) from > ARIN for the 12 months prior to the approval of a transfer request. This > restriction does not include M&A transfers." Timetable for implementation: > Immediate > _______________________________________________ > 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 scottleibrand at gmail.com Mon Jul 28 20:07:14 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 28 Jul 2014 17:07:14 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - July 2014 In-Reply-To: <2005BBF2470E4243A4286D61C22711B3@ncsscfoipoxes4> References: <53CEB9B0.9030804@arin.net> <53CEBFB3.2090701@linuxmagic.com> <2005BBF2470E4243A4286D61C22711B3@ncsscfoipoxes4> Message-ID: To follow up on this, here are the relevant portions of the ARIN Staff Assessment that was just posted to PPML along with the revised version of the policy: A. ARIN Staff Comments > The impact of inter-RIR transfers of ASNs on ARIN from both an > operational and development perspective are nominal today, but pose an > unknown (but at least moderate) impact over the medium-term due to > potentially significant impacts for additional requirements and/or > specifications necessary for RPKI support of inter-RIR ASN transfers. > > 3. Resource Impact > This policy would have minimal to moderate resource impact from an > implementation aspect. It is estimated that implementation would occur > within 3 - 9 months after ratification by the ARINBoard of Trustees. The > following would be needed in order to implement: > Future impact from RPKI implementation could involve either some kind of > RIR<->IANA<->RIR coordination system or ERX for ASNs > Updated guidelines and internal procedures > Staff training -Scott On Wed, Jul 23, 2014 at 12:41 PM, Mike Burns wrote: > I support further discussion of the RPKI issue. > I don't think it will be difficult to overcome the issues raised by Mr. > Huston, but since demand for Inter-RIR ASN transfers is low, there is > little harm in waiting to get it right. > I know there were some procedural wrinkles involved in early Inter-RIR > address transfers and we may be able to anticipate and work around these > kinds of things through further discussion. > > > > > ----- Original Message ----- > *From:* Scott Leibrand > *To:* Michael Peddemors > *Cc:* ARIN-PPML List > *Sent:* Wednesday, July 23, 2014 1:54 PM > *Subject:* Re: [arin-ppml] Advisory Council Meeting Results - July 2014 > > On Tue, Jul 22, 2014 at 3:59 PM, Scott Leibrand > wrote: > >> On Tue, Jul 22, 2014 at 12:46 PM, Michael Peddemors < >> michael at linuxmagic.com> wrote: >> >> The AC is continuing to work on the following: >> >> >>> Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers >>>> >>> >>> +1, all logical, can't really see how that can be abused. >>> >> >> The main concern now is the impact of Inter-RIR ASN Transfers on the RPKI >> system. Geoff brought up the issue at the NANOG PPC in Bellevue, >> > > To respond to a private query, Geoff's comments can be reviewed at > https://www.arin.net/participate/meetings/reports/ppc_nanog61/ppc_transcript.html#anchor_14 > > -Scott > > >> and the subsequent staff assessment highlighted the fact that ARIN >> would need to do additional RPKI development to make Inter-RIR ASN >> transfers work with RPKI. Therefore, most of the AC felt (and convinced me) >> that we shouldn't recommend ARIN-2014-15 for adoption after Baltimore, but >> rather should leave it as a Draft Policy and discuss the RPKI issues there. >> >> -Scott >> >> > > ------------------------------ > > _______________________________________________ > 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 Wed Jul 30 11:27:28 2014 From: jcurran at arin.net (John Curran) Date: Wed, 30 Jul 2014 15:27:28 +0000 Subject: [arin-ppml] =?windows-1252?q?Call_for_Nominations_to_ARIN_AC_and_?= =?windows-1252?q?ARIN_Board_=96_Reminder?= References: <53D90880.8020502@arin.net> Message-ID: <7E0DC68C-559C-436E-BE34-B0684DC97051@corp.arin.net> Folks - Anyone can become a member of the ARIN Board or ARIN AC - if you are interested, please have an ARIN Member nominate you today for the upcoming ARIN Elections. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] Call for Nominations ? Reminder Date: July 30, 2014 at 11:00:16 AM EDT To: > Nominations close on 20 August 2014 for candidates for the upcoming ARIN election to fill two seats on the ARIN Board of Trustees and seven seats on the Advisory Council (AC). We are also seeking nominations for one seat on the Number Resource Organization Number Council (NRO NC) which will be appointed by the Board of Trustees. Elections will be held in October, and the winning candidates will be seated on 31 December 2014. Who can submit a nomination? You must be a Trustee or an ARIN General Member in Good Standing to make nominations for the Board and Advisory Council. However, those nominated do not need to be ARIN members. Self-nominations from General Members in Good Standing are permitted. Any individual, regardless of ARIN membership status, may self-nominate or nominate one or more candidates for any open NRO NC position. For complete details on the nomination process, visit the ARIN Election System Instructions page at: https://www.arin.net/participate/elections/instructions.html#nominate Ready to submit a nomination? Go to: https://www.arin.net/public/election/ All nominations for the Board and AC elections will be reviewed by the Nomination Committee (NomCom). For more NomCom information, see the NomCom Charter at: https://www.arin.net/about_us/committeecharters.html#nomcom Please direct any questions to info at arin.net. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: