From bononlines at gmail.com Thu Nov 6 16:24:40 2014 From: bononlines at gmail.com (Bon Onlines) Date: Thu, 6 Nov 2014 22:24:40 +0100 Subject: [arin-ppml] ARIN IPs and Spammers? Message-ID: Hey all, What do you think about the number of ARIN ips belongs to spammers nowadays? I have done a researched recently and found alot companies how have assigned more than thousands of IPs to some spammers around the world. Do you think such assignments are fair? Shouldn't arin take some steps to stop such abuses of ips? I would be happy to hear your thoughts. Thanks From michael at linuxmagic.com Thu Nov 6 17:36:25 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 06 Nov 2014 14:36:25 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: Message-ID: <545BF7E9.505@linuxmagic.com> On 14-11-06 01:24 PM, Bon Onlines wrote: > Hey all, > > What do you think about the number of ARIN ips belongs to spammers > nowadays? I have done a researched recently and found alot companies > how have assigned more than thousands of IPs to some spammers around > the world. > > Do you think such assignments are fair? Shouldn't arin take some steps > to stop such abuses of ips? > > I would be happy to hear your thoughts. > > Thanks > _______________________________________________ You don't REALLY want to hear my thoughts on this.. Even worse, the IPv4 runout is encouraging providers to use up all their available IP space in anyway they can, and spammers are a ready taker :) And it does strain credulity that spammers somehow need several /16's.. Unfortunately, it isn't ARIN's mandate (at this time) to make any kind of judgement on the usage, only that it is used.. Which of course does set up the possibility for what many would consider an abuse of the systems.. But, if you are a spammer, I am sure they believe they have a right to them.. The system does work that way though.. Get a /24, fill it up with spammers, and you can get more space .. and so on, and so on... What you need to do is ask, is there a better system? If so, how to get that to be part of ARIN's mandate.. but trust me, concensus on even this is hard... -- "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 bononlines at gmail.com Thu Nov 6 17:48:37 2014 From: bononlines at gmail.com (Bon Onlines) Date: Thu, 6 Nov 2014 23:48:37 +0100 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: <545BF7E9.505@linuxmagic.com> References: <545BF7E9.505@linuxmagic.com> Message-ID: Michael, I recently got some spams from some IPs within an ISP( datacenter ) and contacted them regarding that, however their respond to me was something like : ---------------------------------- We are unable to find DNSBL listings supporting that this client is a spammer. In determining whether to deem a client a "spammer", we use only the most well-respected and authoritative blacklists, such as Spamhaus. Unfortunately, reputation-based websites like Senderbase don't help in this determination, as they remove all the relevant diagnostic information. Our client has handled the very few abuse issues that they have received in a prompt and concise manner. If you find hard evidence that any of our clients are engaging in spam, please send a report with as much detail as possible to us. We strive for transparency in our abuse process, so we invite you to CC Spamhaus on any reports that you send. [...] does take spamming seriously and are not tolerant of any spam activities. ---------------------------------- However if I give you the ip addresses and their as number you will see that all the rdns records are something like garbage.garbage.com and this is definetly used for spams. I am not sure if they are keeping him for money ... More than 1K ip or even more. it might made them more than 2-3K $ monthly ... The more important from my end as an end user is that ARIN has to take some actions for such companies and retrive their ip assignments. I would like to hear from you all and also someone at ARIN about this matter. Thanks On Thu, Nov 6, 2014 at 11:36 PM, Michael Peddemors wrote: > On 14-11-06 01:24 PM, Bon Onlines wrote: >> >> Hey all, >> >> What do you think about the number of ARIN ips belongs to spammers >> nowadays? I have done a researched recently and found alot companies >> how have assigned more than thousands of IPs to some spammers around >> the world. >> >> Do you think such assignments are fair? Shouldn't arin take some steps >> to stop such abuses of ips? >> >> I would be happy to hear your thoughts. >> >> Thanks >> _______________________________________________ > > > You don't REALLY want to hear my thoughts on this.. > > Even worse, the IPv4 runout is encouraging providers to use up all their > available IP space in anyway they can, and spammers are a ready taker :) > > And it does strain credulity that spammers somehow need several /16's.. > > Unfortunately, it isn't ARIN's mandate (at this time) to make any kind of > judgement on the usage, only that it is used.. > > Which of course does set up the possibility for what many would consider an > abuse of the systems.. > > But, if you are a spammer, I am sure they believe they have a right to > them.. > > The system does work that way though.. > > Get a /24, fill it up with spammers, and you can get more space .. > and so on, and so on... > > What you need to do is ask, is there a better system? If so, how to get > that to be part of ARIN's mandate.. but trust me, concensus on even this is > hard... > > > > > > -- > "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 owen at delong.com Thu Nov 6 18:59:19 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Nov 2014 15:59:19 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: Message-ID: In a word, no. ARIN should not be the application police and should not be making value judgments about what addresses are used for. While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. Owen > On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: > > Hey all, > > What do you think about the number of ARIN ips belongs to spammers > nowadays? I have done a researched recently and found alot companies > how have assigned more than thousands of IPs to some spammers around > the world. > > Do you think such assignments are fair? Shouldn't arin take some steps > to stop such abuses of ips? > > I would be happy to hear your thoughts. > > 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. From bob at digilink.net Thu Nov 6 19:33:34 2014 From: bob at digilink.net (Bob Atkins) Date: Thu, 06 Nov 2014 16:33:34 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: Message-ID: <545C135E.7050809@digilink.net> Trying to regulate IPv4 address space based on who and how it is used is a waste of time anyway. Just wait until spammers start using IPv6 space. On 11/6/2014 3:59 PM, Owen DeLong wrote: > In a word, no. > > ARIN should not be the application police and should not be making value judgments about what addresses are used for. > > While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. > > Owen > >> On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: >> >> Hey all, >> >> What do you think about the number of ARIN ips belongs to spammers >> nowadays? I have done a researched recently and found alot companies >> how have assigned more than thousands of IPs to some spammers around >> the world. >> >> Do you think such assignments are fair? Shouldn't arin take some steps >> to stop such abuses of ips? >> >> I would be happy to hear your thoughts. >> >> 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. > _______________________________________________ > 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. > -- Untitled Document *Bob Atkins * /President/CEO/ *DigiLink, Inc. * Business Inter-net-working */The Cure for the Common ISP!/* Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: bob at digilink.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DigiLink_esig_logo.jpg Type: image/jpeg Size: 23605 bytes Desc: not available URL: From rgrant at skywaywest.com Thu Nov 6 19:41:12 2014 From: rgrant at skywaywest.com (Ron Grant) Date: Thu, 06 Nov 2014 16:41:12 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: Message-ID: <545C1528.5030205@skywaywest.com> "First they came for the spammers, and I said nothing, because I sent no spam" On 2014-11-06 3:59 PM, Owen DeLong wrote: > In a word, no. > > ARIN should not be the application police and should not be making value judgments about what addresses are used for. > > While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. > > Owen > >> On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: >> >> Hey all, >> >> What do you think about the number of ARIN ips belongs to spammers >> nowadays? I have done a researched recently and found alot companies >> how have assigned more than thousands of IPs to some spammers around >> the world. >> >> Do you think such assignments are fair? Shouldn't arin take some steps >> to stop such abuses of ips? >> >> I would be happy to hear your thoughts. >> >> 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. > _______________________________________________ > 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. -- Ron Grant Managed DSL/T1/Wireless/Fibre Skyway West Business Internet Internet and Private Networking rgrant at skywaywest.com Bonding and Fail Over Solutions ph: 604 737 2113 Virtual Data Centre and Private Clouds fax: 604 482 1299 http://www.skywaywest.com Sales, Support and Billing http://www.skywaywest.com/contact-us.htm ca.linkedin.com/in/obiron From narten at us.ibm.com Fri Nov 7 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 07 Nov 2014 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201411070553.sA75r3rP020575@rotala.raleigh.ibm.com> Total of 7 messages in the last 7 days. script run at: Fri Nov 7 00:53:02 EST 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 1 | 51.18% | 45144 | bob at digilink.net 28.57% | 2 | 17.32% | 15276 | bononlines at gmail.com 14.29% | 1 | 8.39% | 7403 | rgrant at skywaywest.com 14.29% | 1 | 8.04% | 7090 | michael at linuxmagic.com 14.29% | 1 | 7.64% | 6735 | narten at us.ibm.com 14.29% | 1 | 7.43% | 6558 | owen at delong.com --------+------+--------+----------+------------------------ 100.00% | 7 |100.00% | 88206 | Total From John at qxccommunications.com Fri Nov 7 01:50:27 2014 From: John at qxccommunications.com (John Von Stein) Date: Fri, 7 Nov 2014 06:50:27 +0000 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: <545C135E.7050809@digilink.net> References: <545C135E.7050809@digilink.net> Message-ID: Should Colt be held accountable to police the use of hand guns? Or Pfizer for medication schedule compliance? Or teachers for our children's grades? The point is that ARIN is the administrator of IP numbers but each of us is responsible for the proper use of them. That said, without enforcement there is no rule of law so the question really is what entity needs to be the enforcer? The Federal Reserve Bank assesses economic conditions and sets interest rates but it is the Bank Auditor Army that enforces regulatory compliance on the banks themselves. Much like the Fed, IP addresses need to have a segregation of duties between policy-setting and enforcement. Clearly ARIN is in the policy-setting role already and that's where they should stay in my humble opinion. The question is who/what will be the "Bank Examiner" regarding the appropriate use of IP addresses going forward????? This whole discussion thread is not about technology, it's about governance. Thank you, John W. Von Stein CEO [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bob Atkins Sent: Thursday, November 6, 2014 7:34 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN IPs and Spammers? Trying to regulate IPv4 address space based on who and how it is used is a waste of time anyway. Just wait until spammers start using IPv6 space. On 11/6/2014 3:59 PM, Owen DeLong wrote: In a word, no. ARIN should not be the application police and should not be making value judgments about what addresses are used for. While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. Owen On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: Hey all, What do you think about the number of ARIN ips belongs to spammers nowadays? I have done a researched recently and found alot companies how have assigned more than thousands of IPs to some spammers around the world. Do you think such assignments are fair? Shouldn't arin take some steps to stop such abuses of ips? I would be happy to hear your thoughts. 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. _______________________________________________ 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. -- Bob Atkins President/CEO [DigiLink, Inc.] Business Inter-net-working The Cure for the Common ISP! Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: bob at digilink.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 23605 bytes Desc: image002.jpg URL: From bononlines at gmail.com Fri Nov 7 06:07:24 2014 From: bononlines at gmail.com (Bon Onlines) Date: Fri, 7 Nov 2014 12:07:24 +0100 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: <545C135E.7050809@digilink.net> Message-ID: Hello John, " The point is that ARIN is the administrator of IP numbers but each of us is responsible for the proper use of them. " This statement is correct, but the main point is, why should ARIN assign more IPs to the companies who are abusing their own IP Assignments? If ARIN is the administrator of IP numbers, so they have to have atleast a control and monitor on new assignment to its clients. The issue is, if a spammer comes to you and ask for a huge block of IPs, this is a win win business for you and the spammer. ( specially more benefit for you as an ISP ) because you have got the money from the spammer to assign him the huge block of IP, you IPs are all in used and you can ask more IPs from ARIN, ARIN will assign you another huge block of IP without checking how you did used the old one before? were they givven to spammers? were they abused? and you have now a new virgin block which cann be givven to another spammer and you will earn more. Who will make profit here? Yes, for sure, you as an ISP, the Spammer ... BUT the people are being abused and getting more and more spamms daily, hourly and soon secondly if the IPv6 comes ... My concern is, ARIN has to have more monitor and control of its IP assinments. Is that alot to ask from them ? On Fri, Nov 7, 2014 at 7:50 AM, John Von Stein wrote: > Should Colt be held accountable to police the use of hand guns? Or > Pfizer for medication schedule compliance? Or teachers for our children?s > grades? > > > > The point is that ARIN is the administrator of IP numbers but each of us > is responsible for the proper use of them. That said, without enforcement > there is no rule of law so the question really is what entity needs to be > the enforcer? The Federal Reserve Bank assesses economic conditions and > sets interest rates but it is the Bank Auditor Army that enforces > regulatory compliance on the banks themselves. > > > > Much like the Fed, IP addresses need to have a segregation of duties > between policy-setting and enforcement. Clearly ARIN is in the > policy-setting role already and that?s where they should stay in my humble > opinion. The question is who/what will be the ?Bank Examiner? regarding > the appropriate use of IP addresses going forward????? > > > > This whole discussion thread is not about technology, it?s about > governance. > > > > Thank you, > > John W. Von Stein > > CEO > > > > [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] > > > > 102 NE 2nd Street > > Suite 136 > > Boca Raton, FL 33432 > > Office: 561-288-6989 > > www.QxCcommunications.com > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Bob Atkins > *Sent:* Thursday, November 6, 2014 7:34 PM > *To:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] ARIN IPs and Spammers? > > > > > Trying to regulate IPv4 address space based on who and how it is used is a > waste of time anyway. > > Just wait until spammers start using IPv6 space. > > On 11/6/2014 3:59 PM, Owen DeLong wrote: > > In a word, no. > > > > ARIN should not be the application police and should not be making value judgments about what addresses are used for. > > > > While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. > > > > Owen > > > > On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: > > > > Hey all, > > > > What do you think about the number of ARIN ips belongs to spammers > > nowadays? I have done a researched recently and found alot companies > > how have assigned more than thousands of IPs to some spammers around > > the world. > > > > Do you think such assignments are fair? Shouldn't arin take some steps > > to stop such abuses of ips? > > > > I would be happy to hear your thoughts. > > > > 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. > > > > _______________________________________________ > > 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. > > > > > > -- > > *Bob Atkins * > > *President/CEO* > > *[image: DigiLink, Inc.] * > Business Inter-net-working > *The Cure for the Common ISP!* > > Phone: (310) 577-9450 > Fax: (310) 577-3360 > eMail: bob at digilink.net > > > > _______________________________________________ > 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: 2999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 23605 bytes Desc: not available URL: From John at qxccommunications.com Fri Nov 7 07:19:43 2014 From: John at qxccommunications.com (John Von Stein) Date: Fri, 7 Nov 2014 12:19:43 +0000 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: <545C135E.7050809@digilink.net> Message-ID: Agreed, and as mentioned below, there is no rule-of-law without enforcement. So the question is who or what should be the enforcement (police, judge) of proper IP usage? I don?t think that?s ARIN?s role. ARIN makes the rules (as does the House and Senate) but Congress certainly is not tasked with enforcement and actually needs enforcement to ensure that they follow their own rules. We appear to be missing the enforcement piece of the IP puzzle and abuse will continue until we put that piece in place. Trial by email distribution list is not the answer but it appears that there is aneed for some type of formal structure / entity / committee / jury system / elected panel of judges or whatever ? that is empowered by ARIN to carry out enforcement and acknowledged by all as such. - john This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. From: Bon Onlines [mailto:bononlines at gmail.com] Sent: Friday, November 7, 2014 6:07 AM To: John Von Stein Cc: Bob Atkins; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN IPs and Spammers? Hello John, " The point is that ARIN is the administrator of IP numbers but each of us is responsible for the proper use of them. " This statement is correct, but the main point is, why should ARIN assign more IPs to the companies who are abusing their own IP Assignments? If ARIN is the administrator of IP numbers, so they have to have atleast a control and monitor on new assignment to its clients. The issue is, if a spammer comes to you and ask for a huge block of IPs, this is a win win business for you and the spammer. ( specially more benefit for you as an ISP ) because you have got the money from the spammer to assign him the huge block of IP, you IPs are all in used and you can ask more IPs from ARIN, ARIN will assign you another huge block of IP without checking how you did used the old one before? were they givven to spammers? were they abused? and you have now a new virgin block which cann be givven to another spammer and you will earn more. Who will make profit here? Yes, for sure, you as an ISP, the Spammer ... BUT the people are being abused and getting more and more spamms daily, hourly and soon secondly if the IPv6 comes ... My concern is, ARIN has to have more monitor and control of its IP assinments. Is that alot to ask from them ? On Fri, Nov 7, 2014 at 7:50 AM, John Von Stein > wrote: Should Colt be held accountable to police the use of hand guns? Or Pfizer for medication schedule compliance? Or teachers for our children?s grades? The point is that ARIN is the administrator of IP numbers but each of us is responsible for the proper use of them. That said, without enforcement there is no rule of law so the question really is what entity needs to be the enforcer? The Federal Reserve Bank assesses economic conditions and sets interest rates but it is the Bank Auditor Army that enforces regulatory compliance on the banks themselves. Much like the Fed, IP addresses need to have a segregation of duties between policy-setting and enforcement. Clearly ARIN is in the policy-setting role already and that?s where they should stay in my humble opinion. The question is who/what will be the ?Bank Examiner? regarding the appropriate use of IP addresses going forward????? This whole discussion thread is not about technology, it?s about governance. Thank you, John W. Von Stein CEO [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bob Atkins Sent: Thursday, November 6, 2014 7:34 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN IPs and Spammers? Trying to regulate IPv4 address space based on who and how it is used is a waste of time anyway. Just wait until spammers start using IPv6 space. On 11/6/2014 3:59 PM, Owen DeLong wrote: In a word, no. ARIN should not be the application police and should not be making value judgments about what addresses are used for. While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. Owen On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: Hey all, What do you think about the number of ARIN ips belongs to spammers nowadays? I have done a researched recently and found alot companies how have assigned more than thousands of IPs to some spammers around the world. Do you think such assignments are fair? Shouldn't arin take some steps to stop such abuses of ips? I would be happy to hear your thoughts. 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. _______________________________________________ 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. -- Bob Atkins President/CEO [DigiLink, Inc.] Business Inter-net-working The Cure for the Common ISP! Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: bob at digilink.net _______________________________________________ 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: 2999 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 23605 bytes Desc: image002.jpg URL: From dogwallah at gmail.com Fri Nov 7 07:51:19 2014 From: dogwallah at gmail.com (McTim) Date: Fri, 7 Nov 2014 06:51:19 -0600 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: <545C135E.7050809@digilink.net> Message-ID: On Fri, Nov 7, 2014 at 6:19 AM, John Von Stein wrote: > Agreed, and as mentioned below, there is no rule-of-law without > enforcement. > > > > So the question is who or what should be the enforcement (police, judge) > of proper IP usage? I don?t think that?s ARIN?s role. > The role of ARIN (the secretariat) is to carry out (enforce) the Policies set by the ARIN community. We as ARIN (the policy community, or "Congress" in your analogy) have to tell the secretariat what is an appropriate usage of IP resources. So far, the community has not (yet) gone down the rabbit hole of trying to restrict certain uses of Internet resources based upon value judgements. If you have a policy proposal that separates the wheat from chaff in an objective manner, I am sure that will generate considerable discussion. Please contact info at arin.net if you experience any issues. > > > > > -- > > *Bob Atkins * > > *President/CEO* > > *[image: DigiLink, Inc.] * > Business Inter-net-working > *The Cure for the Common ISP!* > > Phone: (310) 577-9450 > Fax: (310) 577-3360 > eMail: bob at digilink.net > > > > > _______________________________________________ > 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. > -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 23605 bytes Desc: not available URL: From matthew at matthew.at Fri Nov 7 09:33:10 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 7 Nov 2014 06:33:10 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: <545C135E.7050809@digilink.net> Message-ID: Who regulates the "appropriate use" of street addresses? Matthew Kaufman (Sent from my iPhone) > On Nov 6, 2014, at 10:50 PM, John Von Stein wrote: > > Should Colt be held accountable to police the use of hand guns? Or Pfizer for medication schedule compliance? Or teachers for our children?s grades? > > The point is that ARIN is the administrator of IP numbers but each of us is responsible for the proper use of them. That said, without enforcement there is no rule of law so the question really is what entity needs to be the enforcer? The Federal Reserve Bank assesses economic conditions and sets interest rates but it is the Bank Auditor Army that enforces regulatory compliance on the banks themselves. > > Much like the Fed, IP addresses need to have a segregation of duties between policy-setting and enforcement. Clearly ARIN is in the policy-setting role already and that?s where they should stay in my humble opinion. The question is who/what will be the ?Bank Examiner? regarding the appropriate use of IP addresses going forward????? > > This whole discussion thread is not about technology, it?s about governance. > > Thank you, > John W. Von Stein > CEO > > > > 102 NE 2nd Street > Suite 136 > Boca Raton, FL 33432 > Office: 561-288-6989 > www.QxCcommunications.com > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bob Atkins > Sent: Thursday, November 6, 2014 7:34 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN IPs and Spammers? > > > Trying to regulate IPv4 address space based on who and how it is used is a waste of time anyway. > > Just wait until spammers start using IPv6 space. > > On 11/6/2014 3:59 PM, Owen DeLong wrote: > In a word, no. > > ARIN should not be the application police and should not be making value judgments about what addresses are used for. > > While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. > > Owen > > On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: > > Hey all, > > What do you think about the number of ARIN ips belongs to spammers > nowadays? I have done a researched recently and found alot companies > how have assigned more than thousands of IPs to some spammers around > the world. > > Do you think such assignments are fair? Shouldn't arin take some steps > to stop such abuses of ips? > > I would be happy to hear your thoughts. > > 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. > > _______________________________________________ > 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. > > > -- > Bob Atkins > President/CEO > > Business Inter-net-working > The Cure for the Common ISP! > > Phone: (310) 577-9450 > Fax: (310) 577-3360 > eMail: bob at digilink.net > > > > _______________________________________________ > 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 Fri Nov 7 14:00:01 2014 From: bill at herrin.us (William Herrin) Date: Fri, 7 Nov 2014 14:00:01 -0500 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: Message-ID: On Thu, Nov 6, 2014 at 4:24 PM, Bon Onlines wrote: > What do you think about the number of ARIN ips belongs to spammers > nowadays? I think ARIN shouldn't be in the anti-spam business and I think they'd do more harm than good if they tried. Spam is tricky. It involves unappealable value judgments that we really don't want the -monopoly- registry operator to make. That having been said, it'd be nice if a few more network operators at the two-steps-removed level would make those judgments. I'm tired of the service providers that connect the bulletproof hosters getting no grief from their own backbone providers. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Nov 7 20:30:27 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Nov 2014 17:30:27 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: <545C135E.7050809@digilink.net> Message-ID: <098D9A95-FEA8-446B-9DC9-90F16FF3D164@delong.com> The Municipal government (city, county, etc.) in conjunction with the Planning department usually sets the policies by which they are issued. The police and/or code enforcement divisions of the municipal government generally take care of the enforcement side. Not sure how this relates to the discussion at hand. Owen > On Nov 7, 2014, at 6:33 AM, Matthew Kaufman wrote: > > Who regulates the "appropriate use" of street addresses? > > Matthew Kaufman > > (Sent from my iPhone) > > On Nov 6, 2014, at 10:50 PM, John Von Stein > wrote: > >> Should Colt be held accountable to police the use of hand guns? Or Pfizer for medication schedule compliance? Or teachers for our children?s grades? >> >> The point is that ARIN is the administrator of IP numbers but each of us is responsible for the proper use of them. That said, without enforcement there is no rule of law so the question really is what entity needs to be the enforcer? The Federal Reserve Bank assesses economic conditions and sets interest rates but it is the Bank Auditor Army that enforces regulatory compliance on the banks themselves. >> >> Much like the Fed, IP addresses need to have a segregation of duties between policy-setting and enforcement. Clearly ARIN is in the policy-setting role already and that?s where they should stay in my humble opinion. The question is who/what will be the ?Bank Examiner? regarding the appropriate use of IP addresses going forward????? >> >> This whole discussion thread is not about technology, it?s about governance. >> >> Thank you, >> John W. Von Stein >> CEO >> >> >> >> 102 NE 2nd Street >> Suite 136 >> Boca Raton, FL 33432 >> Office: 561-288-6989 >> www.QxCcommunications.com >> >> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Bob Atkins >> Sent: Thursday, November 6, 2014 7:34 PM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN IPs and Spammers? >> >> >> Trying to regulate IPv4 address space based on who and how it is used is a waste of time anyway. >> >> Just wait until spammers start using IPv6 space. >> >> On 11/6/2014 3:59 PM, Owen DeLong wrote: >> In a word, no. >> >> ARIN should not be the application police and should not be making value judgments about what addresses are used for. >> >> While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. >> >> Owen >> >> On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: >> >> Hey all, >> >> What do you think about the number of ARIN ips belongs to spammers >> nowadays? I have done a researched recently and found alot companies >> how have assigned more than thousands of IPs to some spammers around >> the world. >> >> Do you think such assignments are fair? Shouldn't arin take some steps >> to stop such abuses of ips? >> >> I would be happy to hear your thoughts. >> >> 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. >> >> _______________________________________________ >> 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. >> >> >> -- >> Bob Atkins >> President/CEO >> >> Business Inter-net-working >> The Cure for the Common ISP! >> >> Phone: (310) 577-9450 >> Fax: (310) 577-3360 >> eMail: bob at digilink.net >> >> >> _______________________________________________ >> 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 matthew at matthew.at Fri Nov 7 22:44:51 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 7 Nov 2014 19:44:51 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: <098D9A95-FEA8-446B-9DC9-90F16FF3D164@delong.com> References: <545C135E.7050809@digilink.net> <098D9A95-FEA8-446B-9DC9-90F16FF3D164@delong.com> Message-ID: <73223F6D-F402-4207-90C1-5E70598F4976@matthew.at> If I send a bunch of junk mail from my house, or play music really loud late at night, does the city come and take my street address away? Matthew Kaufman (Sent from my iPhone) > On Nov 7, 2014, at 5:30 PM, Owen DeLong wrote: > > The Municipal government (city, county, etc.) in conjunction with the Planning department usually sets the policies by which they are issued. > > The police and/or code enforcement divisions of the municipal government generally take care of the enforcement side. > > Not sure how this relates to the discussion at hand. > > Owen > >> On Nov 7, 2014, at 6:33 AM, Matthew Kaufman wrote: >> >> Who regulates the "appropriate use" of street addresses? >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >>> On Nov 6, 2014, at 10:50 PM, John Von Stein wrote: >>> >>> Should Colt be held accountable to police the use of hand guns? Or Pfizer for medication schedule compliance? Or teachers for our children?s grades? >>> >>> The point is that ARIN is the administrator of IP numbers but each of us is responsible for the proper use of them. That said, without enforcement there is no rule of law so the question really is what entity needs to be the enforcer? The Federal Reserve Bank assesses economic conditions and sets interest rates but it is the Bank Auditor Army that enforces regulatory compliance on the banks themselves. >>> >>> Much like the Fed, IP addresses need to have a segregation of duties between policy-setting and enforcement. Clearly ARIN is in the policy-setting role already and that?s where they should stay in my humble opinion. The question is who/what will be the ?Bank Examiner? regarding the appropriate use of IP addresses going forward????? >>> >>> This whole discussion thread is not about technology, it?s about governance. >>> >>> Thank you, >>> John W. Von Stein >>> CEO >>> >>> >>> >>> 102 NE 2nd Street >>> Suite 136 >>> Boca Raton, FL 33432 >>> Office: 561-288-6989 >>> www.QxCcommunications.com >>> >>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. >>> >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bob Atkins >>> Sent: Thursday, November 6, 2014 7:34 PM >>> To: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] ARIN IPs and Spammers? >>> >>> >>> Trying to regulate IPv4 address space based on who and how it is used is a waste of time anyway. >>> >>> Just wait until spammers start using IPv6 space. >>> >>> On 11/6/2014 3:59 PM, Owen DeLong wrote: >>> In a word, no. >>> >>> ARIN should not be the application police and should not be making value judgments about what addresses are used for. >>> >>> While I support industry efforts to eliminate SPAM and support ARIN taking action against inefficient utilization of address space (such as snowshoe spamming), I do not think that we want to go down the very slippery slope of appointing ARIN arbiter of what is good and bad usage of internet addresses. >>> >>> Owen >>> >>> On Nov 6, 2014, at 1:24 PM, Bon Onlines wrote: >>> >>> Hey all, >>> >>> What do you think about the number of ARIN ips belongs to spammers >>> nowadays? I have done a researched recently and found alot companies >>> how have assigned more than thousands of IPs to some spammers around >>> the world. >>> >>> Do you think such assignments are fair? Shouldn't arin take some steps >>> to stop such abuses of ips? >>> >>> I would be happy to hear your thoughts. >>> >>> 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. >>> >>> _______________________________________________ >>> 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. >>> >>> >>> -- >>> Bob Atkins >>> President/CEO >>> >>> Business Inter-net-working >>> The Cure for the Common ISP! >>> >>> Phone: (310) 577-9450 >>> Fax: (310) 577-3360 >>> eMail: bob at digilink.net >>> >>> >>> >>> _______________________________________________ >>> 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 Sat Nov 8 00:48:55 2014 From: bill at herrin.us (William Herrin) Date: Sat, 8 Nov 2014 00:48:55 -0500 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: <73223F6D-F402-4207-90C1-5E70598F4976@matthew.at> References: <545C135E.7050809@digilink.net> <098D9A95-FEA8-446B-9DC9-90F16FF3D164@delong.com> <73223F6D-F402-4207-90C1-5E70598F4976@matthew.at> Message-ID: On Fri, Nov 7, 2014 at 10:44 PM, Matthew Kaufman wrote: > If I send a bunch of junk mail from my house, or play music really > loud late at night, does the city come and take my street address away? The city arrives in the form of police who politely ask if you'd like to spend the night at a different address with a somewhat more restricted egress. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? -------------- next part -------------- An HTML attachment was scrubbed... URL: From John at qxccommunications.com Sat Nov 8 10:23:36 2014 From: John at qxccommunications.com (John Von Stein) Date: Sat, 8 Nov 2014 15:23:36 +0000 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance Message-ID: This does not need to be ?eye for an eye? enforcement. Just like a speeding, beyond the safety issues involved the deterrent against doing it partially the cost of the fine and the increased insurance premium but mostly is the fear of losing the privilege, not the right, to drive. Repeated or an egregious offense will lead to someone?s driver?s license being revoked. If we define the use of IP addresses as a privilege, not a right, granted by ARIN then it is possible to build Acceptable Use rules on that founding principle. These Acceptable Use rules become the foundation for enforcement. We will then need a judicial system (IP Court) of sort so the rules can be enforced fairly and equitably across the user population. The judges can be elected by the ARIN membership with term limits to ensure that equity and fairness are maintained over time. Much of the policing ?Neighborhood Crime Watch? is already in place with many opportunities for an innocent to report spam or other abuses. The problem is that not much can be done once that abuse is reported other than for the ISP to block that IP address. I am suggesting that we need to take the next step in the maturity progression of IP Address administration by defining the use of IP addresses as a privilege, defining Acceptable Use rules and creating an applicable enforcement / judicial system. Right now WWW stands for Wild, Wild West where it?s every man for himself with a judge named Colt with six 45-caliber jurors. As an individual and/or ISP I can block an IP address (lock my door), report the abuser to various black lists (picture in the Post Office), etc but only if there was a crime committed in the real world (fraud, theft, child pornography, copyright infringement, etc) can the weight of a judicial system come to bear. We need a parallel system within the IP Address world. There will be a lot of gray area and fuzzy lines even with Acceptable Use rules in place (Advertising vs. Spam, login attempt vs. DDOS, etc). Many of the cases will have to rely on the fairness and equity of the knowledgeable judges/arbitrators involved who will have to administer their duties to the best of his/her ability and we, as ARIN members, will need to back these decisions up by supporting and abiding by those decisions. The Supreme Court admitted that it is difficult to define obscenity yet it was very clear on its authority to make case by case decisions on what is obscene or not (?I know it when I see it?). IP Address abuse is going to be very difficult to draw a crisp, bright line around. We all acknowledge that IP abuse is happening but we currently have no way to officially judge and/or correct the situation even when we see it. For the record, I am not an attorney nor desire to be a judge, juror or in any way be involved with enforcement or to make money or gain favor or influence of any type from this endeavor. As an active industry participant I have a vested interest in and feel a responsibility to help mature and evolve IP Address administration as the mission critical fundamental building block that it is for all IP based technology development to come. Abuse tends to get worse until some governing force takes control of the situation. We either do this for ourselves, such as a Commodity exchange/clearinghouse SRO (Self-Regulatory Organization) or it will be put in place on us such as the Securities & Exchange Commission (SEC) which governs stock exchanges. I have worked in both environments and, believe me, if we need to be regulated then SRO is a much better place to be over time. Thank you, John W. Von Stein CEO [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Saturday, November 8, 2014 12:49 AM To: Matthew Kaufman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN IPs and Spammers? On Fri, Nov 7, 2014 at 10:44 PM, Matthew Kaufman > wrote: > If I send a bunch of junk mail from my house, or play music really > loud late at night, does the city come and take my street address away? The city arrives in the form of police who politely ask if you'd like to spend the night at a different address with a somewhat more restricted egress. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: From mcr at sandelman.ca Sat Nov 8 13:00:55 2014 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 08 Nov 2014 13:00:55 -0500 Subject: [arin-ppml] ARIN IPs and Spammers? In-Reply-To: References: <545C135E.7050809@digilink.net> <098D9A95-FEA8-446B-9DC9-90F16FF3D164@delong.com> <73223F6D-F402-4207-90C1-5E70598F4976@matthew.at> Message-ID: <2371.1415469655@sandelman.ca> William Herrin wrote: >> If I send a bunch of junk mail from my house, or play music really >> loud late at night, does the city come and take my street address >> away? > The city arrives in the form of police who politely ask if you'd like > to spend the night at a different address with a somewhat more > restricted egress. And, at some point, you may find that they took the entire house away, but left the number on the house. (In our world, they would likely let you keep the house, but you'd have no egress onto that street). Alternatively, they might enter your house, and remove the offending process. So, yes, sometimes they do take your address on that street away. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From dogwallah at gmail.com Sat Nov 8 14:53:22 2014 From: dogwallah at gmail.com (McTim) Date: Sat, 8 Nov 2014 13:53:22 -0600 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: References: Message-ID: On Sat, Nov 8, 2014 at 9:23 AM, John Von Stein wrote: > This does not need to be ?eye for an eye? enforcement. > > > > Just like a speeding, beyond the safety issues involved the deterrent > against doing it partially the cost of the fine and the increased insurance > premium but mostly is the fear of losing the privilege, not the right, to > drive. Repeated or an egregious offense will lead to someone?s driver?s > license being revoked. > > > > If we define the use of IP addresses as a privilege, not a right, granted > by ARIN then it is possible to build Acceptable Use rules on that founding > principle. > Possible, yes, but is it desirable? So far no RIR policy community has gotten into the deeply murky issue of content regulation (which is what many would call it if we were to create an anti-spam policy). You are free to write such a policy and see if you can get agreement from the community. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: From John at qxccommunications.com Sat Nov 8 18:26:32 2014 From: John at qxccommunications.com (John Von Stein) Date: Sat, 8 Nov 2014 23:26:32 +0000 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: References: Message-ID: Very simple ? Use a preliminary panel of experts like a Grand Jury to render an opinion if the case merits a deeper look via an official judge/arbitrator. This is how commodity trading disputes get resolved quickly. The decision of the arbitrator is binding under the SRO rules. The general guidelines of what is okay vs. not okay will quickly get defined with the first few cases. Obviously for there to be a case in the first place then someone must have complained and had enough data to back it up. The Grand jury applies the rule ?I will know it if I see it?. A deep history of case decisions will be a much better definition than what anyone could possibly craft in a few paragraphs. Thank you, John W. Von Stein [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. From: McTim [mailto:dogwallah at gmail.com] Sent: Saturday, November 8, 2014 2:53 PM To: John Von Stein Cc: William Herrin; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN IPs and Spammers? => Need for Governance On Sat, Nov 8, 2014 at 9:23 AM, John Von Stein > wrote: This does not need to be ?eye for an eye? enforcement. Just like a speeding, beyond the safety issues involved the deterrent against doing it partially the cost of the fine and the increased insurance premium but mostly is the fear of losing the privilege, not the right, to drive. Repeated or an egregious offense will lead to someone?s driver?s license being revoked. If we define the use of IP addresses as a privilege, not a right, granted by ARIN then it is possible to build Acceptable Use rules on that founding principle. Possible, yes, but is it desirable? So far no RIR policy community has gotten into the deeply murky issue of content regulation (which is what many would call it if we were to create an anti-spam policy). You are free to write such a policy and see if you can get agreement from the community. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: From tedm at ipinc.net Sat Nov 8 19:57:22 2014 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 08 Nov 2014 16:57:22 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: References: Message-ID: <545EBBF2.5020502@ipinc.net> I for one would never support such a proposal. I will point out the United States invented the Internet. This is something that EVERY OTHER COUNTRY IN THE WORLD has to accept. They may not like to admit it even to themselves but they know it's true. The United States modeled the Internet based on the "US publishing world" meaning that speech - ie: publishing - on the Internet is under First Amendment protection. In short, there are no prohibitions on it. That is why the very structure of the TCP/IP protocol itself does not carry anything in it that helps to identify content, or make it easier for people wanting to prohibit certain content. This is why you cannot run VoIP traffic over the Internet (without it sounding like a child's Skype toy) because networks do not honor or pay attention to traffic content - VoIP traffic is given the same priority as data traffic. Other countries such as China which have totalitarian governments that do not have freedom of speech, had to accept the United State's definition of what the Internet is - that is, no prohibitions. In order to advance their filtering agendas they have had to "tack on" content filters. (ie: The Great Firewall) And there are many more people in the world who would like to control other people by denying or filtering content. From the Ayatollas in Iran to the dictators in China to the religious nutcases who still have a lot of control in counties like Mexico, there is no shortage of people who would like to prohibit something on the Internet. It would be a great evil for the RIR system to get involved in that. Once you opened the door to denying spammers, the small-brained retrogrades in the Vatican and other places that want to control speech and who currently don't understand the Internet, would realize that they could accomplish their goals of bringing another Dark Ages on the world by interfering in the RIR system. If you live in the United States - where free speech is required by law - would you trust that censor button in the hands of a typical Republican politician? And those are people in the US who are required by law NOT to censor!!! There is no parallel to financial trading or any of that. And I will point out that financial contracts are violated ALL THE TIME by governments with impunity. When the United States freezes bank accounts of an overseas government to protest something they break hundreds if not thousands of contracts. And people get old and die waiting for their money. The arbitration system has no control over that sort of thing. So to claim that the financial arbitration system is a model of how the RIR's could implement something is absolutely ridiculous. Ted On 11/8/2014 11:53 AM, McTim wrote: > > > On Sat, Nov 8, 2014 at 9:23 AM, John Von Stein > > wrote: > > This does not need to be ?eye for an eye? enforcement. ____ > > __ __ > > Just like a speeding, beyond the safety issues involved the > deterrent against doing it partially the cost of the fine and the > increased insurance premium but mostly is the fear of losing the > privilege, not the right, to drive. Repeated or an egregious > offense will lead to someone?s driver?s license being revoked. ____ > > __ __ > > If we define the use of IP addresses as a privilege, not a right, > granted by ARIN then it is possible to build Acceptable Use rules on > that founding principle. > > > > Possible, yes, but is it desirable? > > > So far no RIR policy community has gotten into the deeply murky issue of > content regulation (which is what many would call it if we were to > create an anti-spam policy). > > You are free to write such a policy and see if you can get agreement > from the community. > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > > > _______________________________________________ > 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 kkargel at polartel.com Mon Nov 10 10:34:05 2014 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 10 Nov 2014 09:34:05 -0600 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <545EBBF2.5020502@ipinc.net> References: <545EBBF2.5020502@ipinc.net> Message-ID: <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> I have to agree with Ted. ARIN is not in the 'acceptable use enforcement' business and that is a line that should not be crossed. There are many other agencies and venues more appropriate for the task of spam regulation. ARIN is not a first amendment police, and they are not responsible for misuse of member networks. ARIN's sole job is registration of IP number resources. I am 100% in favor of limiting and restricting spam and other malicious internet abuses, but ARIN is not the appropriate agency to assign the onus of policing these bad actors. I applaud all the efforts to fight spam and encourage everyone to become much more active and involved in combatting it, but please do it from a proper agency. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Saturday, November 08, 2014 6:57 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN IPs and Spammers? => Need for Governance > > I for one would never support such a proposal. > > I will point out the United States invented the Internet. This is something > that EVERY OTHER COUNTRY IN THE WORLD has to accept. They may not like > to admit it even to themselves but they know it's true. > > The United States modeled the Internet based on the "US publishing world" > meaning that speech - ie: publishing - on the Internet is under First > Amendment protection. In short, there are no prohibitions on it. > > That is why the very structure of the TCP/IP protocol itself does not carry > anything in it that helps to identify content, or make it easier for people > wanting to prohibit certain content. This is why you cannot run VoIP traffic > over the Internet (without it sounding like a child's Skype toy) because > networks do not honor or pay attention to traffic content - VoIP traffic is > given the same priority as data traffic. > > Other countries such as China which have totalitarian governments that do > not have freedom of speech, had to accept the United State's definition of > what the Internet is - that is, no prohibitions. In order to advance their > filtering agendas they have had to "tack on" content filters. (ie: The Great > Firewall) > > And there are many more people in the world who would like to control > other people by denying or filtering content. From the Ayatollas in Iran to > the dictators in China to the religious nutcases who still have a lot of control in > counties like Mexico, there is no shortage of people who would like to > prohibit something on the Internet. > > It would be a great evil for the RIR system to get involved in that. > Once you opened the door to denying spammers, the small-brained > retrogrades in the Vatican and other places that want to control speech and > who currently don't understand the Internet, would realize that they could > accomplish their goals of bringing another Dark Ages on the world by > interfering in the RIR system. > > If you live in the United States - where free speech is required by law > - would you trust that censor button in the hands of a typical Republican > politician? And those are people in the US who are required by law NOT to > censor!!! > > There is no parallel to financial trading or any of that. And I will point out that > financial contracts are violated ALL THE TIME by governments with impunity. > > When the United States freezes bank accounts of an overseas government > to protest something they break hundreds if not thousands of contracts. > And people get old and die waiting for their money. The arbitration system > has no control over that sort of thing. So to claim that the financial arbitration > system is a model of how the RIR's could implement something is absolutely > ridiculous. > > Ted > > On 11/8/2014 11:53 AM, McTim wrote: > > > > > > On Sat, Nov 8, 2014 at 9:23 AM, John Von Stein > > > wrote: > > > > This does not need to be "eye for an eye" enforcement. ____ > > > > __ __ > > > > Just like a speeding, beyond the safety issues involved the > > deterrent against doing it partially the cost of the fine and the > > increased insurance premium but mostly is the fear of losing the > > privilege, not the right, to drive. Repeated or an egregious > > offense will lead to someone's driver's license being revoked. > > ____ > > > > __ __ > > > > If we define the use of IP addresses as a privilege, not a right, > > granted by ARIN then it is possible to build Acceptable Use rules on > > that founding principle. > > > > > > > > Possible, yes, but is it desirable? > > > > > > So far no RIR policy community has gotten into the deeply murky issue > > of content regulation (which is what many would call it if we were to > > create an anti-spam policy). > > > > You are free to write such a policy and see if you can get agreement > > from the community. > > > > > > -- > > Cheers, > > > > McTim > > "A name indicates what we seek. An address indicates where it is. A > > route indicates how we get there." Jon Postel > > > > > > _______________________________________________ > > 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 michael at linuxmagic.com Mon Nov 10 10:56:10 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 10 Nov 2014 07:56:10 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> Message-ID: <5460E01A.6010200@linuxmagic.com> On 14-11-10 07:34 AM, Kevin Kargel wrote: > I have to agree with Ted. ARIN is not in the 'acceptable use enforcement' business and that is a line that should not be crossed. There are many other agencies and venues more appropriate for the task of spam regulation. ARIN is not a first amendment police, and they are not responsible for misuse of member networks. ARIN's sole job is registration of IP number resources. > > I am 100% in favor of limiting and restricting spam and other malicious internet abuses, but ARIN is not the appropriate agency to assign the onus of policing these bad actors. I applaud all the efforts to fight spam and encourage everyone to become much more active and involved in combatting it, but please do it from a proper agency. > > Kevin However, ARIN does have the mandate regarding proper SWIP for delegated IP Addresses, and enforcement in that area might be the first step. Many of those 'spammers' use forged or false information, and while ARIN is not the right place to judge the usage of IP(s), it does have the mandate to determine whether an organization is entitled to new resources. This is a 'first step' which I believe ARIN needs more support in addressing, and stronger mandates in this area. This would help prevent abuse. Usage of a public resource such as an IP Address, should have clearly presented, accurate information as to the party using and responsible for such activity. Some providers are very forward in this regard, requiring identification of users/organizations who wish to use their IP resources, and using 'rwhois' servers and/or SWIP to clearly report this, while others simply ignore ARIN guidelines, can't be bothered, or turn a blind eye. It would be helpful to deal with the later in a more effective way, than simply 'taking a report' of this occurring. There are many 'can-spam' laws etc, that can address spammers, however if the information of the operators is false, inaccurate, or missing, that brings extra challenges. I believe if the information was more accurate, it would also curb some of that activity, freeing up IP addresses for better use. -- "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 kkargel at polartel.com Mon Nov 10 11:17:58 2014 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 10 Nov 2014 10:17:58 -0600 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <5460E01A.6010200@linuxmagic.com> References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> <5460E01A.6010200@linuxmagic.com> Message-ID: <8695009A81378E48879980039EEDAD28015C6D550F@MAIL1.polartel.local> Are you suggesting ARIN start suspending networks with unresponsive POC's? I would have to think hard before supporting that approach. I would support a proposal that no new resources be issued to any organization with an unresponsive 'admin|tech|abuse' POC. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Michael Peddemors > Sent: Monday, November 10, 2014 9:56 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN IPs and Spammers? => Need for Governance > > On 14-11-10 07:34 AM, Kevin Kargel wrote: > > I have to agree with Ted. ARIN is not in the 'acceptable use enforcement' > business and that is a line that should not be crossed. There are many other > agencies and venues more appropriate for the task of spam regulation. ARIN > is not a first amendment police, and they are not responsible for misuse of > member networks. ARIN's sole job is registration of IP number resources. > > > > I am 100% in favor of limiting and restricting spam and other malicious > internet abuses, but ARIN is not the appropriate agency to assign the onus of > policing these bad actors. I applaud all the efforts to fight spam and > encourage everyone to become much more active and involved in > combatting it, but please do it from a proper agency. > > > > Kevin > > However, ARIN does have the mandate regarding proper SWIP for delegated > IP Addresses, and enforcement in that area might be the first step. > > Many of those 'spammers' use forged or false information, and while ARIN is > not the right place to judge the usage of IP(s), it does have the mandate to > determine whether an organization is entitled to new resources. > > This is a 'first step' which I believe ARIN needs more support in addressing, > and stronger mandates in this area. > > This would help prevent abuse. Usage of a public resource such as an IP > Address, should have clearly presented, accurate information as to the party > using and responsible for such activity. > > Some providers are very forward in this regard, requiring identification of > users/organizations who wish to use their IP resources, and using 'rwhois' > servers and/or SWIP to clearly report this, while others simply ignore ARIN > guidelines, can't be bothered, or turn a blind eye. > > It would be helpful to deal with the later in a more effective way, than simply > 'taking a report' of this occurring. > > There are many 'can-spam' laws etc, that can address spammers, however if > the information of the operators is false, inaccurate, or missing, that brings > extra challenges. > > I believe if the information was more accurate, it would also curb some of > that activity, freeing up IP addresses for better use. > > > > > -- > "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 bill at herrin.us Mon Nov 10 11:18:50 2014 From: bill at herrin.us (William Herrin) Date: Mon, 10 Nov 2014 11:18:50 -0500 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <5460E01A.6010200@linuxmagic.com> References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> <5460E01A.6010200@linuxmagic.com> Message-ID: On Mon, Nov 10, 2014 at 10:56 AM, Michael Peddemors wrote: > However, ARIN does have the mandate regarding proper SWIP for > delegated IP Addresses, and enforcement in that area might be the first step. Suggest a useful penalty (within ARIN's organizational scope) for the discovery of forged SWIP information. Something a "bulletproof hoster" wouldn't roll his eyes at but that isn't devastating to a business hit with a false positive. Also, suggest a process ARIN might use to distinguish between those who were tricked (i.e. victims) versus those who were complicit. It is, after all, trivial to anonymously buy a pre-paid debit card and forge a fax-quality image of a driver's license. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon Nov 10 14:27:00 2014 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 10 Nov 2014 11:27:00 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <5460E01A.6010200@linuxmagic.com> References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> <5460E01A.6010200@linuxmagic.com> Message-ID: <54611184.6010604@ipinc.net> On 11/10/2014 7:56 AM, Michael Peddemors wrote: > On 14-11-10 07:34 AM, Kevin Kargel wrote: >> I have to agree with Ted. ARIN is not in the 'acceptable use >> enforcement' business and that is a line that should not be crossed. >> There are many other agencies and venues more appropriate for the task >> of spam regulation. ARIN is not a first amendment police, and they are >> not responsible for misuse of member networks. ARIN's sole job is >> registration of IP number resources. >> >> I am 100% in favor of limiting and restricting spam and other >> malicious internet abuses, but ARIN is not the appropriate agency to >> assign the onus of policing these bad actors. I applaud all the >> efforts to fight spam and encourage everyone to become much more >> active and involved in combatting it, but please do it from a proper >> agency. >> >> Kevin > > However, ARIN does have the mandate regarding proper SWIP for delegated > IP Addresses, and enforcement in that area might be the first step. > > Many of those 'spammers' use forged or false information, and while ARIN > is not the right place to judge the usage of IP(s), it does have the > mandate to determine whether an organization is entitled to new resources. > > This is a 'first step' which I believe ARIN needs more support in > addressing, and stronger mandates in this area. > > This would help prevent abuse. Usage of a public resource such as an IP > Address, should have clearly presented, accurate information as to the > party using and responsible for such activity. > > Some providers are very forward in this regard, requiring identification > of users/organizations who wish to use their IP resources, and using > 'rwhois' servers and/or SWIP to clearly report this, while others simply > ignore ARIN guidelines, can't be bothered, or turn a blind eye. > > It would be helpful to deal with the later in a more effective way, than > simply 'taking a report' of this occurring. > > There are many 'can-spam' laws etc, that can address spammers, however > if the information of the operators is false, inaccurate, or missing, > that brings extra challenges. > > I believe if the information was more accurate, it would also curb some > of that activity, freeing up IP addresses for better use. > > There are many other criminals than spammers on the Internet that make use of forged or fake information that is given to their upstream networks. I do not support penalizing the upstream address holders for this, however. BUT, what I DO think should be happening is when evidence of a bogus SWIP entry is presented to the RIR, the RIR should be able to give the upstream holder a week to investigate, and if the upstream holder is unwilling to "back" the bogus SWIP, then the upstream holder should remove the entry - or ARIN should. I do NOT regard this as penalizing the address holder. Fundamentally, when an address holder obtains addressing they are responsible for it's use. If an address holder wants to become the world's spam and criminal hoster, that is perfectly fine with me. I'll block all their IP addressing in my own gear. But they should not be permitted to use the SWIP system to obfuscate what they are doing. If they want to host spammers, then either the spammers identify who they are - so they can be easily found and prosecuted - or they assume responsibility for the spamming - so they themselves can be prosecuted. If doing that results in removal of SWIP records and their inability to meet utilization requirements to obtain more addressing then that is just their tough luck. Unfortunately, most of this discussion is purely academic for ARIN as most spamming originates either overseas (where ARIN is not the responsible RIR) or it originates from hijacked machines on legitimate networks in North America which will shut them down if informed. Ted > > From tedm at ipinc.net Mon Nov 10 14:36:29 2014 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 10 Nov 2014 11:36:29 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <8695009A81378E48879980039EEDAD28015C6D550F@MAIL1.polartel.local> References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> <5460E01A.6010200@linuxmagic.com> <8695009A81378E48879980039EEDAD28015C6D550F@MAIL1.polartel.local> Message-ID: <546113BD.5020705@ipinc.net> On 11/10/2014 8:17 AM, Kevin Kargel wrote: > Are you suggesting ARIN start suspending networks with unresponsive POC's? I would have to think hard before supporting that approach. > > I would support a proposal that no new resources be issued to any organization with an unresponsive 'admin|tech|abuse' POC. > Hi Kevin, It's already policy. POCs that are unresponsive are supposed to be marked in the database as unresponsive. ARIN is also supposed to further investigate them and mark them invalid. That is implied by Section 3.6.1 of the policy manual Invalid POCs by definition cannot be used as justification for meeting the numerical requirements for utilization in order to obtain more addressing. Is it your view that this process is not happening? Is ARIN not making available a list of these invalid POCs via bulk Whois as the policy requires? Ted > Kevin > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Michael Peddemors >> Sent: Monday, November 10, 2014 9:56 AM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN IPs and Spammers? => Need for Governance >> >> On 14-11-10 07:34 AM, Kevin Kargel wrote: >>> I have to agree with Ted. ARIN is not in the 'acceptable use enforcement' >> business and that is a line that should not be crossed. There are many other >> agencies and venues more appropriate for the task of spam regulation. ARIN >> is not a first amendment police, and they are not responsible for misuse of >> member networks. ARIN's sole job is registration of IP number resources. >>> >>> I am 100% in favor of limiting and restricting spam and other malicious >> internet abuses, but ARIN is not the appropriate agency to assign the onus of >> policing these bad actors. I applaud all the efforts to fight spam and >> encourage everyone to become much more active and involved in >> combatting it, but please do it from a proper agency. >>> >>> Kevin >> >> However, ARIN does have the mandate regarding proper SWIP for delegated >> IP Addresses, and enforcement in that area might be the first step. >> >> Many of those 'spammers' use forged or false information, and while ARIN is >> not the right place to judge the usage of IP(s), it does have the mandate to >> determine whether an organization is entitled to new resources. >> >> This is a 'first step' which I believe ARIN needs more support in addressing, >> and stronger mandates in this area. >> >> This would help prevent abuse. Usage of a public resource such as an IP >> Address, should have clearly presented, accurate information as to the party >> using and responsible for such activity. >> >> Some providers are very forward in this regard, requiring identification of >> users/organizations who wish to use their IP resources, and using 'rwhois' >> servers and/or SWIP to clearly report this, while others simply ignore ARIN >> guidelines, can't be bothered, or turn a blind eye. >> >> It would be helpful to deal with the later in a more effective way, than simply >> 'taking a report' of this occurring. >> >> There are many 'can-spam' laws etc, that can address spammers, however if >> the information of the operators is false, inaccurate, or missing, that brings >> extra challenges. >> >> I believe if the information was more accurate, it would also curb some of >> that activity, freeing up IP addresses for better use. >> >> >> >> >> -- >> "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. > > _______________________________________________ > 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 michael at linuxmagic.com Mon Nov 10 14:49:34 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 10 Nov 2014 11:49:34 -0800 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <54611184.6010604@ipinc.net> References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> <5460E01A.6010200@linuxmagic.com> <54611184.6010604@ipinc.net> Message-ID: <546116CE.1000105@linuxmagic.com> On 14-11-10 11:27 AM, Ted Mittelstaedt wrote: > Unfortunately, most of this discussion is purely academic for ARIN as > most spamming originates either overseas (where ARIN is not the > responsible RIR) or it originates from hijacked machines on legitimate > networks in North America which will shut them down if informed. > > Ted Oh I wish that was only true :0 -- "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 hannigan at gmail.com Mon Nov 10 17:19:19 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 10 Nov 2014 17:19:19 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: Message-ID: +ppml Hello. Happy to provide some answers, but I'll note that you're not on the AC so I'm surprised that you're representing the AC. Inline On Mon, Nov 10, 2014 at 4:36 PM, Jason Schiller wrote: > Marty, > > the ARIN AC is redrafting 2014-19 to respond to comments and staff concerns. > > I brought up your concerns about "evidence of deployment" being to vague and > allowing ARIN to interpret it any way they see fit. There was a suggestion > of adding a non-exclusive list of the types of evidence that should be > acceptable... > Like what? > Unfortunately the AC felt there was no "substantive feedback" on specific > changes. In fact the AC feels the previous attempt was too concrete, and > now we have a vague one which you are concerned is too vague. > Explaining that even if you do submit a "contract" to ARIN, they can't tell if its for one site or another or if its even valid. Sounds pretty substantive to me. > I recall you say, put back the old language, but I looked back at the > 12/2004 NRPM prior to the 2004-5 changes, I checked the 06/2014 NRPM prior > to the 2013-8 changes. And? >None of them have advice to ARIN on how to judge > when an ISP is truly creating a new MDN (and not just committing fraud). > How many fraud "prosecutions" has ARIN initiated in the last three years? > Can us suggest some text along the line of... 'You'ze' can. But I think you mean me. :-) > > "7. Upon verification that the organization has shown evidence of deployment > of the new discrete network site, [such as, but not limited to the > following: a network design showing existing and new discreet networks and > supporting documentation that the proposed design in in progress such as > contracts for new space or power, new equipment orders, publicly available > marketing material describing the offering in a new location, or some other > significant capital investment in the project,] the new networks shall be > allocated: > Let's go back to the original point I made in the last two PPC and ARIN meetings. How can a company contract for real estate, energy or network without knowing if they had IP addresses to operate their business (in this current environment of v4 scarcity and policy wonkery?)? You're suggesting that we create even more conditions for un-qualified staff to evaluate? What kind of energy contract is suitable in this context? mW? mWh? kW? kWh? Min, Max, Capacity, triple peak average? Renting slots on the medium voltage substation or acquiring energy credits from the grid? All of them? None of them? You're proposing non-starters. The collective "we" already sign "officer attestations". If we elaborate our need in a way that justifies the addresses, ARIN should assign them. If they think there's fraud, ARIN should do what they claim they will do and "prosecute". Use Section 12. Complain to the SEC that regulated companies are lying to them. Do something that you can actually have credibility in the sense that someone really understands what they are talking about. So far, #fail. Best, -M< From jschiller at google.com Mon Nov 10 17:36:36 2014 From: jschiller at google.com (Jason Schiller) Date: Mon, 10 Nov 2014 17:36:36 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: Message-ID: Marty, I am not on the AC. As originator I was contacted on the rewrites, and I thought it would be helpful to address your concerns, so I suggested that. The shepherds did not have actionable recommendations, and asked me for text, so I reached out to you. Reading between the lines of your email, would I be correct in concluding there should be no proof of deployment of a new MDN (as this does not give ARIN any more proof to believe deployment of an MDN is likely, and getting approval for the IPs happens before commitment to spend). Simply an engineering plan to do such, and an officer attestation that the engineering plan is indeed truthful, should suffice. If that is the case would the resulting text meet your need? 7. Upon an organization providing plans for a new discreet network, which an officer of the company attests is in progress, the new network shall be allocate: __Jason On Mon, Nov 10, 2014 at 5:19 PM, Martin Hannigan wrote: > +ppml > > Hello. Happy to provide some answers, but I'll note that you're not on > the AC so I'm surprised that you're representing the AC. > > Inline > > > On Mon, Nov 10, 2014 at 4:36 PM, Jason Schiller > wrote: > > Marty, > > > > the ARIN AC is redrafting 2014-19 to respond to comments and staff > concerns. > > > > I brought up your concerns about "evidence of deployment" being to vague > and > > allowing ARIN to interpret it any way they see fit. There was a > suggestion > > of adding a non-exclusive list of the types of evidence that should be > > acceptable... > > > > Like what? > > > > Unfortunately the AC felt there was no "substantive feedback" on specific > > changes. In fact the AC feels the previous attempt was too concrete, and > > now we have a vague one which you are concerned is too vague. > > > > Explaining that even if you do submit a "contract" to ARIN, they can't > tell if its for one site or another or if its even valid. Sounds > pretty substantive to me. > > > I recall you say, put back the old language, but I looked back at the > > 12/2004 NRPM prior to the 2004-5 changes, I checked the 06/2014 NRPM > prior > > to the 2013-8 changes. > > And? > > > >None of them have advice to ARIN on how to judge > > when an ISP is truly creating a new MDN (and not just committing fraud). > > > > How many fraud "prosecutions" has ARIN initiated in the last three years? > > > Can us suggest some text along the line of... > > 'You'ze' can. But I think you mean me. :-) > > > > > > "7. Upon verification that the organization has shown evidence of > deployment > > of the new discrete network site, [such as, but not limited to the > > following: a network design showing existing and new discreet networks > and > > supporting documentation that the proposed design in in progress such as > > contracts for new space or power, new equipment orders, publicly > available > > marketing material describing the offering in a new location, or some > other > > significant capital investment in the project,] the new networks shall be > > allocated: > > > > Let's go back to the original point I made in the last two PPC and > ARIN meetings. How can a company contract for real estate, energy or > network without knowing if they had IP addresses to operate their > business (in this current environment of v4 scarcity and policy > wonkery?)? > > You're suggesting that we create even more conditions for un-qualified > staff to evaluate? What kind of energy contract is suitable in this > context? mW? mWh? kW? kWh? Min, Max, Capacity, triple peak average? > Renting slots on the medium voltage substation or acquiring energy > credits from the grid? All of them? None of them? You're proposing > non-starters. > > The collective "we" already sign "officer attestations". If we > elaborate our need in a way that justifies the addresses, ARIN should > assign them. If they think there's fraud, ARIN should do what they > claim they will do and "prosecute". Use Section 12. Complain to the > SEC that regulated companies are lying to them. Do something that you > can actually have credibility in the sense that someone really > understands what they are talking about. So far, #fail. > > > Best, > > -M< > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From JOHN at egh.com Mon Nov 10 18:17:14 2014 From: JOHN at egh.com (John Santos) Date: Mon, 10 Nov 2014 18:17:14 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: Message-ID: <1141110173410.341A-100000@Ives.egh.com> On Mon, 10 Nov 2014, Martin Hannigan wrote: > > > > "7. Upon verification that the organization has shown evidence of deployment > > of the new discrete network site, [such as, but not limited to the > > following: a network design showing existing and new discreet networks and > > supporting documentation that the proposed design in in progress such as > > contracts for new space or power, new equipment orders, publicly available > > marketing material describing the offering in a new location, or some other > > significant capital investment in the project,] the new networks shall be > > allocated: > > > > Let's go back to the original point I made in the last two PPC and > ARIN meetings. How can a company contract for real estate, energy or > network without knowing if they had IP addresses to operate their > business (in this current environment of v4 scarcity and policy > wonkery?)? Any company with a business plan is taking risks and has to have a fall back plan (even if the plan is "pack it in") for any conceivable eventuality. You want ARIN to guarantee that they can get IPv4 before they've found a site, bought any equipment, signed any contracts with suppliers or customers, or even made any public announcements of their plans to establish a new site? What happens if ARIN says "fine, you can have your IP space", and then when it comes time to allocate it, the cupboard is bare? Or what happens if ARIN supplies some exceedingly scare IP4 to them, and then they can't find real-estate, customers, or some other obstacle prevents them from actually turning on their new network? Do they then get a windfall of salable IPv4? The org trying to set up a new MDN site should have a fallback plan if they can't get ARIN MDN space, of repurposing existing addresses, acquiring them from an upstream, buying them in the market, or using IPv6 instead. If their entire business plan depends on them getting ARIN MDN space (with no other option), then they are being irresponsible to their stakeholders. > > You're suggesting that we create even more conditions for un-qualified > staff to evaluate? What kind of energy contract is suitable in this > context? mW? mWh? kW? kWh? Min, Max, Capacity, triple peak average? > Renting slots on the medium voltage substation or acquiring energy > credits from the grid? All of them? None of them? You're proposing > non-starters. I think you're deliberately being obtuse. It isn't the amount or type of power that matters. What matters is that one method of determining that a site exists is that it is (or soon will be) on the electric grid. What's relevant are the location and dates (i.e. that the contract is current and ongoing) and that the customer be the applicant or someone the applicant is representing. Presenting an electric bill is a perfectly legitimate and common method of establishing residency, which is probably why it's included in the "such as, but not limited to" list. This is not the *ONLY* way to establish the existance of a site, it is merely one of the possible pieces of evidence. Payroll, equipment orders, budgets, networking agreements with upstream providers, site plans, existing, on-going relationship with ARIN can all show that the new site/network is legit. They wouldn't even need to reveal the site's physical location (for example if it were a battered women's shelter, though I can't imagine why one would need an MDN.) You don't need to be an electrical engineer (or do a structural analysis of the building or evaluate the personnel policies of the applicant) to judge the legitimacy of the request. > The collective "we" already sign "officer attestations". If we > elaborate our need in a way that justifies the addresses, ARIN should > assign them. If they think there's fraud, ARIN should do what they > claim they will do and "prosecute". Use Section 12. Complain to the > SEC that regulated companies are lying to them. Do something that you > can actually have credibility in the sense that someone really > understands what they are talking about. So far, #fail. If an org can't demonstrate any form of documentation that the site they are claiming actually exists, an "officer attestation" is worthless. Suing or prosecuting for fraud after the fact is far more difficult and costly (for both parties) than simply requiring evidence up front. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From alh-ietf at tndh.net Mon Nov 10 18:31:24 2014 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 10 Nov 2014 13:31:24 -1000 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> <5460E01A.6010200@linuxmagic.com> Message-ID: <00d701cffd3e$71d30c10$55792430$@tndh.net> >From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin >Sent: Monday, November 10, 2014 6:19 AM >To: Michael Peddemors >Cc: arin-ppml at arin.net >Subject: Re: [arin-ppml] ARIN IPs and Spammers? => Need for Governance > >On Mon, Nov 10, 2014 at 10:56 AM, Michael Peddemors wrote: >> However, ARIN does have the mandate regarding proper SWIP for >> delegated IP Addresses, and enforcement in that area might be the first step. >Suggest a useful penalty (within ARIN's organizational scope) for the discovery of forged SWIP information. Something a >"bulletproof hoster" wouldn't roll his eyes at but that isn't devastating to a business hit with a false positive. > I agree that ARIN should not be involved in enforcement, but one thing that ARIN (and the other RIR's) could do is make it easier for mail server operators to get *ALL* the blocks assigned to a given organization in one query. I find that "whois n w.x.y.z" often returns the same names as either the swip'd client, or the DC host. It would be much easier from my perspective use those names as input then block all of their space than it is to play wack-a-mole as each client cluster shows up. >Also, suggest a process ARIN might use to distinguish between those who were tricked (i.e. victims) versus those who >were complicit. It is, after all, trivial to anonymously buy a pre-paid debit card and forge a fax-quality image of a driver's >license. >-Bill From jschiller at google.com Mon Nov 10 18:38:18 2014 From: jschiller at google.com (Jason Schiller) Date: Mon, 10 Nov 2014 18:38:18 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: <1141110173410.341A-100000@Ives.egh.com> References: <1141110173410.341A-100000@Ives.egh.com> Message-ID: John, Thank you for your comments on the merits of the proposal, but I think it is premature, as we are not sure what the proposal should be. I think we should figure out some straw man text that is agreeable to Martin prior to beating up the proposal. __Jason On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > > > > > > > "7. Upon verification that the organization has shown evidence of > deployment > > > of the new discrete network site, [such as, but not limited to the > > > following: a network design showing existing and new discreet networks > and > > > supporting documentation that the proposed design in in progress such > as > > > contracts for new space or power, new equipment orders, publicly > available > > > marketing material describing the offering in a new location, or some > other > > > significant capital investment in the project,] the new networks shall > be > > > allocated: > > > > > > > Let's go back to the original point I made in the last two PPC and > > ARIN meetings. How can a company contract for real estate, energy or > > network without knowing if they had IP addresses to operate their > > business (in this current environment of v4 scarcity and policy > > wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? What happens if ARIN says "fine, you > can have your IP space", and then when it comes time to allocate it, > the cupboard is bare? Or what happens if ARIN supplies some exceedingly > scare IP4 to them, and then they can't find real-estate, customers, > or some other obstacle prevents them from actually turning on their > new network? Do they then get a windfall of salable IPv4? > > The org trying to set up a new MDN site should have a fallback plan if > they can't get ARIN MDN space, of repurposing existing addresses, > acquiring them from an upstream, buying them in the market, or using IPv6 > instead. If their entire business plan depends on them getting ARIN > MDN space (with no other option), then they are being irresponsible to > their stakeholders. > > > > > You're suggesting that we create even more conditions for un-qualified > > staff to evaluate? What kind of energy contract is suitable in this > > context? mW? mWh? kW? kWh? Min, Max, Capacity, triple peak average? > > Renting slots on the medium voltage substation or acquiring energy > > credits from the grid? All of them? None of them? You're proposing > > non-starters. > > I think you're deliberately being obtuse. It isn't the amount or type of > power that matters. What matters is that one method of determining that a > site exists is that it is (or soon will be) on the electric grid. What's > relevant are the location and dates (i.e. that the contract is current and > ongoing) and that the customer be the applicant or someone the applicant > is representing. > > Presenting an electric bill is a perfectly legitimate and common method of > establishing residency, which is probably why it's included in the "such > as, but not limited to" list. > > > This is not the *ONLY* way to establish the existance of a site, it > is merely one of the possible pieces of evidence. Payroll, equipment > orders, budgets, networking agreements with upstream providers, site > plans, existing, on-going relationship with ARIN can all show that > the new site/network is legit. They wouldn't even need to reveal the > site's physical location (for example if it were a battered women's > shelter, though I can't imagine why one would need an MDN.) > > You don't need to be an electrical engineer (or do a structural > analysis of the building or evaluate the personnel policies of > the applicant) to judge the legitimacy of the request. > > > > The collective "we" already sign "officer attestations". If we > > elaborate our need in a way that justifies the addresses, ARIN should > > assign them. If they think there's fraud, ARIN should do what they > > claim they will do and "prosecute". Use Section 12. Complain to the > > SEC that regulated companies are lying to them. Do something that you > > can actually have credibility in the sense that someone really > > understands what they are talking about. So far, #fail. > > > If an org can't demonstrate any form of documentation that the site > they are claiming actually exists, an "officer attestation" is > worthless. Suing or prosecuting for fraud after the fact is far > more difficult and costly (for both parties) than simply requiring > evidence up front. > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Mon Nov 10 23:55:12 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 10 Nov 2014 23:55:12 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: <1141110173410.341A-100000@Ives.egh.com> References: <1141110173410.341A-100000@Ives.egh.com> Message-ID: On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of deployment >> > of the new discrete network site, [such as, but not limited to the >> > following: a network design showing existing and new discreet networks and >> > supporting documentation that the proposed design in in progress such as >> > contracts for new space or power, new equipment orders, publicly available >> > marketing material describing the offering in a new location, or some other >> > significant capital investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< From David.Huberman at microsoft.com Tue Nov 11 00:08:52 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Nov 2014 05:08:52 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> Message-ID: <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bill at herrin.us Tue Nov 11 00:08:58 2014 From: bill at herrin.us (William Herrin) Date: Tue, 11 Nov 2014 00:08:58 -0500 Subject: [arin-ppml] ARIN IPs and Spammers? => Need for Governance In-Reply-To: <00d701cffd3e$71d30c10$55792430$@tndh.net> References: <545EBBF2.5020502@ipinc.net> <8695009A81378E48879980039EEDAD28015C6D54EE@MAIL1.polartel.local> <5460E01A.6010200@linuxmagic.com> <00d701cffd3e$71d30c10$55792430$@tndh.net> Message-ID: On Mon, Nov 10, 2014 at 6:31 PM, Tony Hain wrote: > I agree that ARIN should not be involved in enforcement, but > one thing that ARIN (and the other RIR's) could do is make it > easier for mail server operators to get *ALL* the blocks > assigned to a given organization in one query. I find that > "whois n w.x.y.z" often returns the same names as either > the swip'd client, or the DC host. It would be much easier > from my perspective use those names as input then block > all of their space than it is to play wack-a-mole as each > client cluster shows up. IIRC, it's possible to get a bulk feed of whois and SWIP data from ARIN. You can then build a private query engine against it which does as you describe. As long as its an internal function (you're not directly providing the data to third parties) and it's not used for spam or other marketing activities, ARIN seems generally amenable to granting such requests. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Tue Nov 11 00:11:31 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 11 Nov 2014 05:11:31 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12016A40FBB2@ENI-MAIL.eclipse-networks.com> I strongly 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 David Huberman Sent: Tuesday, November 11, 2014 12:09 AM To: Martin Hannigan; John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ 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 matthew at matthew.at Tue Nov 11 01:39:10 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 10 Nov 2014 22:39:10 -0800 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> Message-ID: <5461AF0E.1020906@matthew.at> On 11/10/14, 8:55 PM, Martin Hannigan wrote: > This proposal is best summed up as 'wasteful tinkering'. +1 Also, if you have a business plan and need IPv4 space, why not just buy some on the existing transfer market, or do what the big boys are doing and enter into either a right of first refusal or a locked-in future purchase price for enough space to meet your business plan's needs. Then it won't matter which crazy proposals to tweak IPv4 policies at the last minute show up. Even better, deal in legacy space and don't worry if some of those policy changes mean you can't register the transfer in the ARIN database. Matthew Kaufman From jschiller at google.com Tue Nov 11 06:46:18 2014 From: jschiller at google.com (Jason Schiller) Date: Tue, 11 Nov 2014 06:46:18 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: While I appreciate this discussion, I believe there is a real need to change policy. Previously a new MDN could only qualify under and get an initial allocation sized block. This was extended to include more than the initial allocation sized block under immediate need. I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such is the case when an existing MDN is split. Hence 2014-19. I don't want to get hung up on the proof of deployment text that already exists. Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting. Thank you. __Jason On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < David.Huberman at microsoft.com> wrote: > In my world view, policy should never assume the requestor is lying. The > same should hold true for ARIN staff. > > No one ever mandated ARIN with stopping the scammers. I believe it was > Rob Seastrom who posted here a long time ago and basically said that ARIN > staff are entrusted to do the best job they can in running the registry, > but the community shouldn't have expectations that ARIN staff can figure > out who's lying and who's not. > > But because ARIN got burned by large-scale hijacking in the early 2000s, > it has operated under "trust but verify" ever since. And this fosters the > antagonism towards the registry which I think is wholly avoidable. "Trust > but verify" is a bad way to run an RIR, in my experience. > > I hope we can focus on policy language which always assumes a request is > bona fide, and let's stop worrying about the 1% of requestors who are > lying. That way, network engineers can spend less time dealing with ARIN, > and more time running their networks. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Martin Hannigan > Sent: Monday, November 10, 2014 8:55 PM > To: John Santos > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] 2014-19 and evidence of deployment > > On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: > > On Mon, 10 Nov 2014, Martin Hannigan wrote: > > > >> > > >> > "7. Upon verification that the organization has shown evidence of > >> > deployment of the new discrete network site, [such as, but not > >> > limited to the > >> > following: a network design showing existing and new discreet > >> > networks and supporting documentation that the proposed design in > >> > in progress such as contracts for new space or power, new equipment > >> > orders, publicly available marketing material describing the > >> > offering in a new location, or some other significant capital > >> > investment in the project,] the new networks shall be > >> > allocated: > >> > > >> > >> Let's go back to the original point I made in the last two PPC and > >> ARIN meetings. How can a company contract for real estate, energy or > >> network without knowing if they had IP addresses to operate their > >> business (in this current environment of v4 scarcity and policy > >> wonkery?)? > > > > Any company with a business plan is taking risks and has to have a > > fall back plan (even if the plan is "pack it in") for any conceivable > > eventuality. You want ARIN to guarantee that they can get IPv4 before > > they've found a site, bought any equipment, signed any contracts with > > suppliers or customers, or even made any public announcements of their > > plans to establish a new site? > > Let me get this straight. So one should have a business plans that > accounts for spending money that may not actually get to generate any > revenue? ARIN has been assigning addresses without this requirement for a > decade plus. The ability to forward look (guarantee) has been shrunk and > now ARIN is targeting MDN for discriminatory policies and removing any > ability to forward look, a normal practice in "business". > The risk of not getting addresses because ARIN is using clueless > requirements is very high, not average. This isn't a simple excercise of > "win some lose some". There are real dollars at stake (whether you operate > a single rack or 1000 racks regardless of how much "power" you > use) and real risks. > > This proposal is best summed up as 'wasteful tinkering'. > > Best, > > -M< > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Tue Nov 11 07:11:45 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Nov 2014 12:11:45 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com>, Message-ID: J- What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't that leave the staff able to issue blocks to new MDNs under the same rules as everyone else in section 4, while at the same time removing the documentation requirement? Thinking out loud. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller Sent: Tuesday, November 11, 2014 3:46:18 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment While I appreciate this discussion, I believe there is a real need to change policy. Previously a new MDN could only qualify under and get an initial allocation sized block. This was extended to include more than the initial allocation sized block under immediate need. I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such is the case when an existing MDN is split. Hence 2014-19. I don't want to get hung up on the proof of deployment text that already exists. Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting. Thank you. __Jason On Tue, Nov 11, 2014 at 12:08 AM, David Huberman > wrote: In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos > wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue Nov 11 07:43:34 2014 From: jschiller at google.com (Jason Schiller) Date: Tue, 11 Nov 2014 07:43:34 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: David, In the 06/2014 NRPM we had exactly the current policy minus paragraph 7. At that time, we had a policy experience report where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6 for allocations to new MDNs We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum. I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history. I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need. If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7... "7. When an organization declares they are adding a new discrete network site, the new networks shall be allocated: - the minimum allocation size under section 4.2.1.5 - more than the minimum allocation size if the organization can demonstrate additional need using the immediate need criteria (4.2.1.6) - a 3-month supply of address space may be requested if the new MDN can show an applicable demonstrated one-year utilization history." Is that in line with what you are proposing? I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if they believe the organization is not working in good faith) under section 12. Is that about right? __Jason On Tue, Nov 11, 2014 at 7:11 AM, David Huberman < David.Huberman at microsoft.com> wrote: > J- > > What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't > that leave the staff able to issue blocks to new MDNs under the same rules > as everyone else in section 4, while at the same time removing the > documentation requirement? > > Thinking out loud. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > ------------------------------ > *From:* Jason Schiller > *Sent:* Tuesday, November 11, 2014 3:46:18 AM > *To:* David Huberman > *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net > > *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment > > While I appreciate this discussion, I believe there is a real need to > change policy. > > Previously a new MDN could only qualify under and get an initial > allocation sized block. > > This was extended to include more than the initial allocation sized > block under immediate need. > > I believe there is another case (besides immediate need) where more than > the initial allocation sized block is justified. That is when there is a > demonstrated past 1 year growth history that supports a future looking 3 > month growth of a new MDN. Such is the case when an existing MDN is > split. Hence 2014-19. > > I don't want to get hung up on the proof of deployment text that already > exists. > > Those of you that think this should be changed, please provide suitable > text, and we can run the two policy proposals in parallel. > > If you think this is unnecessary tinkering, then I would expect we will > not rat hole on the pre-existing "proof of deployment" text when discussion > 2014-19 as we did in the previous meeting. > > Thank you. > > > __Jason > > > On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > >> In my world view, policy should never assume the requestor is lying. The >> same should hold true for ARIN staff. >> >> No one ever mandated ARIN with stopping the scammers. I believe it was >> Rob Seastrom who posted here a long time ago and basically said that ARIN >> staff are entrusted to do the best job they can in running the registry, >> but the community shouldn't have expectations that ARIN staff can figure >> out who's lying and who's not. >> >> But because ARIN got burned by large-scale hijacking in the early 2000s, >> it has operated under "trust but verify" ever since. And this fosters the >> antagonism towards the registry which I think is wholly avoidable. "Trust >> but verify" is a bad way to run an RIR, in my experience. >> >> I hope we can focus on policy language which always assumes a request is >> bona fide, and let's stop worrying about the 1% of requestors who are >> lying. That way, network engineers can spend less time dealing with ARIN, >> and more time running their networks. >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Martin Hannigan >> Sent: Monday, November 10, 2014 8:55 PM >> To: John Santos >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> >> On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: >> > On Mon, 10 Nov 2014, Martin Hannigan wrote: >> > >> >> > >> >> > "7. Upon verification that the organization has shown evidence of >> >> > deployment of the new discrete network site, [such as, but not >> >> > limited to the >> >> > following: a network design showing existing and new discreet >> >> > networks and supporting documentation that the proposed design in >> >> > in progress such as contracts for new space or power, new equipment >> >> > orders, publicly available marketing material describing the >> >> > offering in a new location, or some other significant capital >> >> > investment in the project,] the new networks shall be >> >> > allocated: >> >> > >> >> >> >> Let's go back to the original point I made in the last two PPC and >> >> ARIN meetings. How can a company contract for real estate, energy or >> >> network without knowing if they had IP addresses to operate their >> >> business (in this current environment of v4 scarcity and policy >> >> wonkery?)? >> > >> > Any company with a business plan is taking risks and has to have a >> > fall back plan (even if the plan is "pack it in") for any conceivable >> > eventuality. You want ARIN to guarantee that they can get IPv4 before >> > they've found a site, bought any equipment, signed any contracts with >> > suppliers or customers, or even made any public announcements of their >> > plans to establish a new site? >> >> Let me get this straight. So one should have a business plans that >> accounts for spending money that may not actually get to generate any >> revenue? ARIN has been assigning addresses without this requirement for a >> decade plus. The ability to forward look (guarantee) has been shrunk and >> now ARIN is targeting MDN for discriminatory policies and removing any >> ability to forward look, a normal practice in "business". >> The risk of not getting addresses because ARIN is using clueless >> requirements is very high, not average. This isn't a simple excercise of >> "win some lose some". There are real dollars at stake (whether you operate >> a single rack or 1000 racks regardless of how much "power" you >> use) and real risks. >> >> This proposal is best summed up as 'wasteful tinkering'. >> >> Best, >> >> -M< >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Tue Nov 11 07:59:13 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Nov 2014 12:59:13 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> , Message-ID: <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com> Something isn't right here. MDN (in basically the 2013 form) existed for 12 years without much of a problem. The language was tinkered a bit for subsequent alloc math, but new sites text wasn't. A new site opening was given: - a /22 or a /20 - dealer's choice since those were the minimums after 2005. Many were issued /20s except for smaller deployments who were happy to take /22s. - more if immediate need justified it. Slow start applies to section 4 requests. So under standard slow start math, you took the /22 or /20, and grow the NEW site with it. Just like an initial alloc to a new ISP. If the site wasn't really new, you could use existing customer counts and apply immediate need. Nothing was broken. A special case like a site split into two is easily handled under the above considerations, isn't it? So ... Either the community has misunderstood Leslie's policy experience report, the report is wrong, or I'm wrong. I stand by my suggestion. Section 7 is unnecessary and, to Marty's point, heavy handed. Now would be a great time for Leslie to jump in :-) Or if you don't accept my experiences in this as helpful, feel free to move on with the thread. Frankly, other than the heavy handedness of paragraph 7, I see no brokenness beyond fringe cases. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller Sent: Tuesday, November 11, 2014 4:43:34 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, In the 06/2014 NRPM we had exactly the current policy minus paragraph 7. At that time, we had a policy experience report where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6 for allocations to new MDNs We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum. I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history. I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need. If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7... "7. When an organization declares they are adding a new discrete network site, the new networks shall be allocated: - the minimum allocation size under section 4.2.1.5 - more than the minimum allocation size if the organization can demonstrate additional need using the immediate need criteria (4.2.1.6) - a 3-month supply of address space may be requested if the new MDN can show an applicable demonstrated one-year utilization history." Is that in line with what you are proposing? I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if they believe the organization is not working in good faith) under section 12. Is that about right? __Jason On Tue, Nov 11, 2014 at 7:11 AM, David Huberman > wrote: J- What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't that leave the staff able to issue blocks to new MDNs under the same rules as everyone else in section 4, while at the same time removing the documentation requirement? Thinking out loud. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 3:46:18 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment While I appreciate this discussion, I believe there is a real need to change policy. Previously a new MDN could only qualify under and get an initial allocation sized block. This was extended to include more than the initial allocation sized block under immediate need. I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such is the case when an existing MDN is split. Hence 2014-19. I don't want to get hung up on the proof of deployment text that already exists. Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting. Thank you. __Jason On Tue, Nov 11, 2014 at 12:08 AM, David Huberman > wrote: In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos > wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue Nov 11 08:18:46 2014 From: jschiller at google.com (Jason Schiller) Date: Tue, 11 Nov 2014 08:18:46 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com> References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: David, I would love to hear from Leslie on your question, maybe we are trying to solve a non-problem. In the mean time I do have one concern about what you wrote WRT an existing MDN site splitting and being fulfilled under immediate need. Imagine you have MDN1 which grew from nothing to a /16 over the last year. You have just crossed 80% utilization, and want to grow into a new /18 which is a 3 month supply. But the region has gotten too big. So you split it into MDN1 and MDN6. Have the pre-existing customers are in MDN1 and half in MDN6, and half the future looking growth is in MDN1 and half in MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6? 1. MDN6 does not have immediate need. The customers moved there kept the former MDN1 addressing. So you would have to start fresh with a /21, and ramp up to a /19. 2. If you were renumbering the customers in MDN6, you would only qualify for as many as you could address in 30 days (this many not be an issue for ISPs because when you re-allocate or assign the addresses they are in use, but for end-users they actually have to be in service I have personally had an issue qualifying for IPs for an end-user under immediate need when I was asking for as many IPs as I had things to number, but couldn't actually complete numbering them in 30 days). So no in two cases I don't think immediate need (which has an intentionally high bar [to be used in exceptional circumstances] )does not work. __Jason On Tue, Nov 11, 2014 at 7:59 AM, David Huberman < David.Huberman at microsoft.com> wrote: > Something isn't right here. > > MDN (in basically the 2013 form) existed for 12 years without much of a > problem. The language was tinkered a bit for subsequent alloc math, but > new sites text wasn't. A new site opening was given: > > - a /22 or a /20 - dealer's choice since those were the minimums after > 2005. Many were issued /20s except for smaller deployments who were happy > to take /22s. > > - more if immediate need justified it. > > Slow start applies to section 4 requests. So under standard slow start > math, you took the /22 or /20, and grow the NEW site with it. Just like an > initial alloc to a new ISP. If the site wasn't really new, you could use > existing customer counts and apply immediate need. Nothing was broken. A > special case like a site split into two is easily handled under the above > considerations, isn't it? > > So ... Either the community has misunderstood Leslie's policy experience > report, the report is wrong, or I'm wrong. > > I stand by my suggestion. Section 7 is unnecessary and, to Marty's point, > heavy handed. > > Now would be a great time for Leslie to jump in :-) Or if you don't > accept my experiences in this as helpful, feel free to move on with the > thread. Frankly, other than the heavy handedness of paragraph 7, I see no > brokenness beyond fringe cases. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > ------------------------------ > *From:* Jason Schiller > *Sent:* Tuesday, November 11, 2014 4:43:34 AM > > *To:* David Huberman > *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment > > David, > > In the 06/2014 NRPM > we had exactly > the current policy minus paragraph 7. > > At that time, we had a policy experience report > > where ARIN staff explained 4.5 has criteria for getting additional > addresses for an existing MDN but no criteria for getting addresses for a > new MDN. ARIN staff communicated that they were using only the Immediate > Need 4.2.1.6 for allocations to new MDNs > > We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs > to include the minimum. > > I am suggesting further 2014-19 to extend it to also consider a 3 month > supply if there is an applicable supporting 1 year use history. > > I suspect if we struck paragraph 7, ARIN would go back to their previous > practice of only applying immediate need, and looking for connectivity > agreements, and giving a /21 or enough to meet 30 day need. > > If you want to completely remove the proof of deployment, I think you > would still need to keep the second half of paragraph 7... > > "7. When an organization declares they are adding a new discrete network > site, the new networks shall be allocated: > > - the minimum allocation size under section 4.2.1.5 > - more than the minimum allocation size if the organization can > demonstrate additional need using the immediate need criteria (4.2.1.6) > - a 3-month supply of address space may be requested if the new MDN can > show an applicable demonstrated one-year utilization history." > > Is that in line with what you are proposing? > > I assume you would conclude that most organization that declare they > have a new MDN are not committing fraud, and will be using the address > within 3 months, and if not in 3 months or more, ARIN is free to reclaim > (if they believe the organization is not working in good faith) under > section 12. > > Is that about right? > > __Jason > > > On Tue, Nov 11, 2014 at 7:11 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > >> J- >> >> What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't >> that leave the staff able to issue blocks to new MDNs under the same rules >> as everyone else in section 4, while at the same time removing the >> documentation requirement? >> >> Thinking out loud. >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> ------------------------------ >> *From:* Jason Schiller >> *Sent:* Tuesday, November 11, 2014 3:46:18 AM >> *To:* David Huberman >> *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net >> >> *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment >> >> While I appreciate this discussion, I believe there is a real need to >> change policy. >> >> Previously a new MDN could only qualify under and get an initial >> allocation sized block. >> >> This was extended to include more than the initial allocation sized >> block under immediate need. >> >> I believe there is another case (besides immediate need) where more >> than the initial allocation sized block is justified. That is when there >> is a demonstrated past 1 year growth history that supports a future looking >> 3 month growth of a new MDN. Such is the case when an existing MDN is >> split. Hence 2014-19. >> >> I don't want to get hung up on the proof of deployment text that >> already exists. >> >> Those of you that think this should be changed, please provide suitable >> text, and we can run the two policy proposals in parallel. >> >> If you think this is unnecessary tinkering, then I would expect we will >> not rat hole on the pre-existing "proof of deployment" text when discussion >> 2014-19 as we did in the previous meeting. >> >> Thank you. >> >> >> __Jason >> >> >> On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < >> David.Huberman at microsoft.com> wrote: >> >>> In my world view, policy should never assume the requestor is lying. >>> The same should hold true for ARIN staff. >>> >>> No one ever mandated ARIN with stopping the scammers. I believe it was >>> Rob Seastrom who posted here a long time ago and basically said that ARIN >>> staff are entrusted to do the best job they can in running the registry, >>> but the community shouldn't have expectations that ARIN staff can figure >>> out who's lying and who's not. >>> >>> But because ARIN got burned by large-scale hijacking in the early 2000s, >>> it has operated under "trust but verify" ever since. And this fosters the >>> antagonism towards the registry which I think is wholly avoidable. "Trust >>> but verify" is a bad way to run an RIR, in my experience. >>> >>> I hope we can focus on policy language which always assumes a request is >>> bona fide, and let's stop worrying about the 1% of requestors who are >>> lying. That way, network engineers can spend less time dealing with ARIN, >>> and more time running their networks. >>> >>> David R Huberman >>> Microsoft Corporation >>> Principal, Global IP Addressing >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>> Behalf Of Martin Hannigan >>> Sent: Monday, November 10, 2014 8:55 PM >>> To: John Santos >>> Cc: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >>> >>> On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: >>> > On Mon, 10 Nov 2014, Martin Hannigan wrote: >>> > >>> >> > >>> >> > "7. Upon verification that the organization has shown evidence of >>> >> > deployment of the new discrete network site, [such as, but not >>> >> > limited to the >>> >> > following: a network design showing existing and new discreet >>> >> > networks and supporting documentation that the proposed design in >>> >> > in progress such as contracts for new space or power, new equipment >>> >> > orders, publicly available marketing material describing the >>> >> > offering in a new location, or some other significant capital >>> >> > investment in the project,] the new networks shall be >>> >> > allocated: >>> >> > >>> >> >>> >> Let's go back to the original point I made in the last two PPC and >>> >> ARIN meetings. How can a company contract for real estate, energy or >>> >> network without knowing if they had IP addresses to operate their >>> >> business (in this current environment of v4 scarcity and policy >>> >> wonkery?)? >>> > >>> > Any company with a business plan is taking risks and has to have a >>> > fall back plan (even if the plan is "pack it in") for any conceivable >>> > eventuality. You want ARIN to guarantee that they can get IPv4 before >>> > they've found a site, bought any equipment, signed any contracts with >>> > suppliers or customers, or even made any public announcements of their >>> > plans to establish a new site? >>> >>> Let me get this straight. So one should have a business plans that >>> accounts for spending money that may not actually get to generate any >>> revenue? ARIN has been assigning addresses without this requirement for a >>> decade plus. The ability to forward look (guarantee) has been shrunk and >>> now ARIN is targeting MDN for discriminatory policies and removing any >>> ability to forward look, a normal practice in "business". >>> The risk of not getting addresses because ARIN is using clueless >>> requirements is very high, not average. This isn't a simple excercise of >>> "win some lose some". There are real dollars at stake (whether you operate >>> a single rack or 1000 racks regardless of how much "power" you >>> use) and real risks. >>> >>> This proposal is best summed up as 'wasteful tinkering'. >>> >>> Best, >>> >>> -M< >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> >> > > > -- > _______________________________________________________ > 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 David.Huberman at microsoft.com Tue Nov 11 08:38:37 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Nov 2014 13:38:37 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com>, Message-ID: You split one site into two sites. The existing addresses go wherever you put them. Your network, your rules. Once a site is 80% and the other condition (50% overall or no /24 free) is met, you ask for more space for that site. That site is not a new. The customers (ISP) or equipment (EU) already existed and the address space already existed. No rule explicitly says staff MUST classify the split sites as new, so staff are free to apply reasoable interpretation to fit the unique situation. Staff should apply regular additional alloc rules for any requests from the split sites. Please note this is beyond a fringe case. We enjoy a fantastic staff who should be free to apply reasonable rules to such a situation, set the new rule as a procedure, and apply consistently as best they are able. Just my opinion. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller Sent: Tuesday, November 11, 2014 5:18:46 AM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, I would love to hear from Leslie on your question, maybe we are trying to solve a non-problem. In the mean time I do have one concern about what you wrote WRT an existing MDN site splitting and being fulfilled under immediate need. Imagine you have MDN1 which grew from nothing to a /16 over the last year. You have just crossed 80% utilization, and want to grow into a new /18 which is a 3 month supply. But the region has gotten too big. So you split it into MDN1 and MDN6. Have the pre-existing customers are in MDN1 and half in MDN6, and half the future looking growth is in MDN1 and half in MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6? 1. MDN6 does not have immediate need. The customers moved there kept the former MDN1 addressing. So you would have to start fresh with a /21, and ramp up to a /19. 2. If you were renumbering the customers in MDN6, you would only qualify for as many as you could address in 30 days (this many not be an issue for ISPs because when you re-allocate or assign the addresses they are in use, but for end-users they actually have to be in service I have personally had an issue qualifying for IPs for an end-user under immediate need when I was asking for as many IPs as I had things to number, but couldn't actually complete numbering them in 30 days). So no in two cases I don't think immediate need (which has an intentionally high bar [to be used in exceptional circumstances] )does not work. __Jason On Tue, Nov 11, 2014 at 7:59 AM, David Huberman > wrote: Something isn't right here. MDN (in basically the 2013 form) existed for 12 years without much of a problem. The language was tinkered a bit for subsequent alloc math, but new sites text wasn't. A new site opening was given: - a /22 or a /20 - dealer's choice since those were the minimums after 2005. Many were issued /20s except for smaller deployments who were happy to take /22s. - more if immediate need justified it. Slow start applies to section 4 requests. So under standard slow start math, you took the /22 or /20, and grow the NEW site with it. Just like an initial alloc to a new ISP. If the site wasn't really new, you could use existing customer counts and apply immediate need. Nothing was broken. A special case like a site split into two is easily handled under the above considerations, isn't it? So ... Either the community has misunderstood Leslie's policy experience report, the report is wrong, or I'm wrong. I stand by my suggestion. Section 7 is unnecessary and, to Marty's point, heavy handed. Now would be a great time for Leslie to jump in :-) Or if you don't accept my experiences in this as helpful, feel free to move on with the thread. Frankly, other than the heavy handedness of paragraph 7, I see no brokenness beyond fringe cases. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 4:43:34 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, In the 06/2014 NRPM we had exactly the current policy minus paragraph 7. At that time, we had a policy experience report where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6 for allocations to new MDNs We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum. I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history. I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need. If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7... "7. When an organization declares they are adding a new discrete network site, the new networks shall be allocated: - the minimum allocation size under section 4.2.1.5 - more than the minimum allocation size if the organization can demonstrate additional need using the immediate need criteria (4.2.1.6) - a 3-month supply of address space may be requested if the new MDN can show an applicable demonstrated one-year utilization history." Is that in line with what you are proposing? I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if they believe the organization is not working in good faith) under section 12. Is that about right? __Jason On Tue, Nov 11, 2014 at 7:11 AM, David Huberman > wrote: J- What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't that leave the staff able to issue blocks to new MDNs under the same rules as everyone else in section 4, while at the same time removing the documentation requirement? Thinking out loud. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 3:46:18 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment While I appreciate this discussion, I believe there is a real need to change policy. Previously a new MDN could only qualify under and get an initial allocation sized block. This was extended to include more than the initial allocation sized block under immediate need. I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such is the case when an existing MDN is split. Hence 2014-19. I don't want to get hung up on the proof of deployment text that already exists. Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting. Thank you. __Jason On Tue, Nov 11, 2014 at 12:08 AM, David Huberman > wrote: In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos > wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ 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 jschiller at google.com Tue Nov 11 10:48:20 2014 From: jschiller at google.com (Jason Schiller) Date: Tue, 11 Nov 2014 10:48:20 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: David, That would suffice if when an org goes from 4 MDNs to 5 MDNs that ARIN does not treat the newly added region as anew MDN, but my understanding that this is not the case. Leslie, can you comment on this practice as well? It was my understanding from the policy experience report that this is not the case. Thanks, __Jason On Tue, Nov 11, 2014 at 8:38 AM, David Huberman < David.Huberman at microsoft.com> wrote: > You split one site into two sites. The existing addresses go wherever > you put them. Your network, your rules. > > Once a site is 80% and the other condition (50% overall or no /24 free) is > met, you ask for more space for that site. That site is not a new. The > customers (ISP) or equipment (EU) already existed and the address space > already existed. No rule explicitly says staff MUST classify the split > sites as new, so staff are free to apply reasoable interpretation to fit > the unique situation. > > Staff should apply regular additional alloc rules for any requests from > the split sites. > > Please note this is beyond a fringe case. We enjoy a fantastic staff who > should be free to apply reasonable rules to such a situation, set the new > rule as a procedure, and apply consistently as best they are able. > > Just my opinion. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > ------------------------------ > *From:* Jason Schiller > *Sent:* Tuesday, November 11, 2014 5:18:46 AM > *To:* David Huberman > *Cc:* arin-ppml at arin.net > > *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment > > David, > > I would love to hear from Leslie on your question, maybe we are trying > to solve a non-problem. > > In the mean time I do have one concern about what you wrote WRT an > existing MDN site splitting and being fulfilled under immediate need. > > Imagine you have MDN1 which grew from nothing to a /16 over the last > year. You have just crossed 80% utilization, and want to grow into a new > /18 which is a 3 month supply. But the region has gotten too big. So you > split it into MDN1 and MDN6. Have the pre-existing customers are in MDN1 > and half in MDN6, and half the future looking growth is in MDN1 and half in > MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 > over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6? > > 1. MDN6 does not have immediate need. The customers moved there kept > the former MDN1 addressing. So you would have to start fresh with a /21, > and ramp up to a /19. > > 2. If you were renumbering the customers in MDN6, you would only qualify > for as many as you could address in 30 days (this many not be an issue for > ISPs because when you re-allocate or assign the addresses they are in use, > but for end-users they actually have to be in service I have personally had > an issue qualifying for IPs for an end-user under immediate need when I was > asking for as many IPs as I had things to number, but couldn't actually > complete numbering them in 30 days). > > So no in two cases I don't think immediate need (which has an > intentionally high bar [to be used in exceptional circumstances] )does not > work. > > __Jason > > > > > > > > > On Tue, Nov 11, 2014 at 7:59 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > >> Something isn't right here. >> >> MDN (in basically the 2013 form) existed for 12 years without much of a >> problem. The language was tinkered a bit for subsequent alloc math, but >> new sites text wasn't. A new site opening was given: >> >> - a /22 or a /20 - dealer's choice since those were the minimums after >> 2005. Many were issued /20s except for smaller deployments who were happy >> to take /22s. >> >> - more if immediate need justified it. >> >> Slow start applies to section 4 requests. So under standard slow start >> math, you took the /22 or /20, and grow the NEW site with it. Just like an >> initial alloc to a new ISP. If the site wasn't really new, you could use >> existing customer counts and apply immediate need. Nothing was broken. A >> special case like a site split into two is easily handled under the above >> considerations, isn't it? >> >> So ... Either the community has misunderstood Leslie's policy experience >> report, the report is wrong, or I'm wrong. >> >> I stand by my suggestion. Section 7 is unnecessary and, to Marty's >> point, heavy handed. >> >> Now would be a great time for Leslie to jump in :-) Or if you don't >> accept my experiences in this as helpful, feel free to move on with the >> thread. Frankly, other than the heavy handedness of paragraph 7, I see no >> brokenness beyond fringe cases. >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> ------------------------------ >> *From:* Jason Schiller >> *Sent:* Tuesday, November 11, 2014 4:43:34 AM >> >> *To:* David Huberman >> *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment >> >> David, >> >> In the 06/2014 NRPM >> we had exactly >> the current policy minus paragraph 7. >> >> At that time, we had a policy experience report >> >> where ARIN staff explained 4.5 has criteria for getting additional >> addresses for an existing MDN but no criteria for getting addresses for a >> new MDN. ARIN staff communicated that they were using only the Immediate >> Need 4.2.1.6 for allocations to new MDNs >> >> We needed 2014-18 to encourage ARIN to open up the criteria for NEW >> MDNs to include the minimum. >> >> I am suggesting further 2014-19 to extend it to also consider a 3 month >> supply if there is an applicable supporting 1 year use history. >> >> I suspect if we struck paragraph 7, ARIN would go back to their >> previous practice of only applying immediate need, and looking for >> connectivity agreements, and giving a /21 or enough to meet 30 day need. >> >> If you want to completely remove the proof of deployment, I think you >> would still need to keep the second half of paragraph 7... >> >> "7. When an organization declares they are adding a new discrete >> network site, the new networks shall be allocated: >> >> - the minimum allocation size under section 4.2.1.5 >> - more than the minimum allocation size if the organization can >> demonstrate additional need using the immediate need criteria (4.2.1.6) >> - a 3-month supply of address space may be requested if the new MDN can >> show an applicable demonstrated one-year utilization history." >> >> Is that in line with what you are proposing? >> >> I assume you would conclude that most organization that declare they >> have a new MDN are not committing fraud, and will be using the address >> within 3 months, and if not in 3 months or more, ARIN is free to reclaim >> (if they believe the organization is not working in good faith) under >> section 12. >> >> Is that about right? >> >> __Jason >> >> >> On Tue, Nov 11, 2014 at 7:11 AM, David Huberman < >> David.Huberman at microsoft.com> wrote: >> >>> J- >>> >>> What if paragraph 7 were struck entirely from existing 4.5 text? >>> Wouldn't that leave the staff able to issue blocks to new MDNs under the >>> same rules as everyone else in section 4, while at the same time removing >>> the documentation requirement? >>> >>> Thinking out loud. >>> >>> David R Huberman >>> Microsoft Corporation >>> Principal, Global IP Addressing >>> ------------------------------ >>> *From:* Jason Schiller >>> *Sent:* Tuesday, November 11, 2014 3:46:18 AM >>> *To:* David Huberman >>> *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net >>> >>> *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment >>> >>> While I appreciate this discussion, I believe there is a real need to >>> change policy. >>> >>> Previously a new MDN could only qualify under and get an initial >>> allocation sized block. >>> >>> This was extended to include more than the initial allocation sized >>> block under immediate need. >>> >>> I believe there is another case (besides immediate need) where more >>> than the initial allocation sized block is justified. That is when there >>> is a demonstrated past 1 year growth history that supports a future looking >>> 3 month growth of a new MDN. Such is the case when an existing MDN is >>> split. Hence 2014-19. >>> >>> I don't want to get hung up on the proof of deployment text that >>> already exists. >>> >>> Those of you that think this should be changed, please provide >>> suitable text, and we can run the two policy proposals in parallel. >>> >>> If you think this is unnecessary tinkering, then I would expect we >>> will not rat hole on the pre-existing "proof of deployment" text when >>> discussion 2014-19 as we did in the previous meeting. >>> >>> Thank you. >>> >>> >>> __Jason >>> >>> >>> On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < >>> David.Huberman at microsoft.com> wrote: >>> >>>> In my world view, policy should never assume the requestor is lying. >>>> The same should hold true for ARIN staff. >>>> >>>> No one ever mandated ARIN with stopping the scammers. I believe it was >>>> Rob Seastrom who posted here a long time ago and basically said that ARIN >>>> staff are entrusted to do the best job they can in running the registry, >>>> but the community shouldn't have expectations that ARIN staff can figure >>>> out who's lying and who's not. >>>> >>>> But because ARIN got burned by large-scale hijacking in the early >>>> 2000s, it has operated under "trust but verify" ever since. And this >>>> fosters the antagonism towards the registry which I think is wholly >>>> avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. >>>> >>>> I hope we can focus on policy language which always assumes a request >>>> is bona fide, and let's stop worrying about the 1% of requestors who are >>>> lying. That way, network engineers can spend less time dealing with ARIN, >>>> and more time running their networks. >>>> >>>> David R Huberman >>>> Microsoft Corporation >>>> Principal, Global IP Addressing >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>>> On Behalf Of Martin Hannigan >>>> Sent: Monday, November 10, 2014 8:55 PM >>>> To: John Santos >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >>>> >>>> On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: >>>> > On Mon, 10 Nov 2014, Martin Hannigan wrote: >>>> > >>>> >> > >>>> >> > "7. Upon verification that the organization has shown evidence of >>>> >> > deployment of the new discrete network site, [such as, but not >>>> >> > limited to the >>>> >> > following: a network design showing existing and new discreet >>>> >> > networks and supporting documentation that the proposed design in >>>> >> > in progress such as contracts for new space or power, new equipment >>>> >> > orders, publicly available marketing material describing the >>>> >> > offering in a new location, or some other significant capital >>>> >> > investment in the project,] the new networks shall be >>>> >> > allocated: >>>> >> > >>>> >> >>>> >> Let's go back to the original point I made in the last two PPC and >>>> >> ARIN meetings. How can a company contract for real estate, energy or >>>> >> network without knowing if they had IP addresses to operate their >>>> >> business (in this current environment of v4 scarcity and policy >>>> >> wonkery?)? >>>> > >>>> > Any company with a business plan is taking risks and has to have a >>>> > fall back plan (even if the plan is "pack it in") for any conceivable >>>> > eventuality. You want ARIN to guarantee that they can get IPv4 before >>>> > they've found a site, bought any equipment, signed any contracts with >>>> > suppliers or customers, or even made any public announcements of their >>>> > plans to establish a new site? >>>> >>>> Let me get this straight. So one should have a business plans that >>>> accounts for spending money that may not actually get to generate any >>>> revenue? ARIN has been assigning addresses without this requirement for a >>>> decade plus. The ability to forward look (guarantee) has been shrunk and >>>> now ARIN is targeting MDN for discriminatory policies and removing any >>>> ability to forward look, a normal practice in "business". >>>> The risk of not getting addresses because ARIN is using clueless >>>> requirements is very high, not average. This isn't a simple excercise of >>>> "win some lose some". There are real dollars at stake (whether you operate >>>> a single rack or 1000 racks regardless of how much "power" you >>>> use) and real risks. >>>> >>>> This proposal is best summed up as 'wasteful tinkering'. >>>> >>>> Best, >>>> >>>> -M< >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the ARIN >>>> Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>> >>> >>> >>> -- >>> _______________________________________________________ >>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >>> >>> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> >> > > > -- > _______________________________________________________ > 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 David.Huberman at microsoft.com Tue Nov 11 10:56:13 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Nov 2014 15:56:13 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com> , Message-ID: Jason, That's not what I said :-) I addressed what I thought you were presenting - a special case where a network takes one discrete site and splits it. In the regular case, described in your email just now, the new site is new. Slow start applies, minus any immediate need justification. It should get whatever prefix between a /24 and a /20 meets the three month need. It has no customers (or it does and immediate need applies) so why should it get more? This is how it always worked and it generally worked well. It's so easy to get more space for a new discrete site, after all. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller Sent: Tuesday, November 11, 2014 7:48:20 AM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, That would suffice if when an org goes from 4 MDNs to 5 MDNs that ARIN does not treat the newly added region as anew MDN, but my understanding that this is not the case. Leslie, can you comment on this practice as well? It was my understanding from the policy experience report that this is not the case. Thanks, __Jason On Tue, Nov 11, 2014 at 8:38 AM, David Huberman > wrote: You split one site into two sites. The existing addresses go wherever you put them. Your network, your rules. Once a site is 80% and the other condition (50% overall or no /24 free) is met, you ask for more space for that site. That site is not a new. The customers (ISP) or equipment (EU) already existed and the address space already existed. No rule explicitly says staff MUST classify the split sites as new, so staff are free to apply reasoable interpretation to fit the unique situation. Staff should apply regular additional alloc rules for any requests from the split sites. Please note this is beyond a fringe case. We enjoy a fantastic staff who should be free to apply reasonable rules to such a situation, set the new rule as a procedure, and apply consistently as best they are able. Just my opinion. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 5:18:46 AM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, I would love to hear from Leslie on your question, maybe we are trying to solve a non-problem. In the mean time I do have one concern about what you wrote WRT an existing MDN site splitting and being fulfilled under immediate need. Imagine you have MDN1 which grew from nothing to a /16 over the last year. You have just crossed 80% utilization, and want to grow into a new /18 which is a 3 month supply. But the region has gotten too big. So you split it into MDN1 and MDN6. Have the pre-existing customers are in MDN1 and half in MDN6, and half the future looking growth is in MDN1 and half in MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6? 1. MDN6 does not have immediate need. The customers moved there kept the former MDN1 addressing. So you would have to start fresh with a /21, and ramp up to a /19. 2. If you were renumbering the customers in MDN6, you would only qualify for as many as you could address in 30 days (this many not be an issue for ISPs because when you re-allocate or assign the addresses they are in use, but for end-users they actually have to be in service I have personally had an issue qualifying for IPs for an end-user under immediate need when I was asking for as many IPs as I had things to number, but couldn't actually complete numbering them in 30 days). So no in two cases I don't think immediate need (which has an intentionally high bar [to be used in exceptional circumstances] )does not work. __Jason On Tue, Nov 11, 2014 at 7:59 AM, David Huberman > wrote: Something isn't right here. MDN (in basically the 2013 form) existed for 12 years without much of a problem. The language was tinkered a bit for subsequent alloc math, but new sites text wasn't. A new site opening was given: - a /22 or a /20 - dealer's choice since those were the minimums after 2005. Many were issued /20s except for smaller deployments who were happy to take /22s. - more if immediate need justified it. Slow start applies to section 4 requests. So under standard slow start math, you took the /22 or /20, and grow the NEW site with it. Just like an initial alloc to a new ISP. If the site wasn't really new, you could use existing customer counts and apply immediate need. Nothing was broken. A special case like a site split into two is easily handled under the above considerations, isn't it? So ... Either the community has misunderstood Leslie's policy experience report, the report is wrong, or I'm wrong. I stand by my suggestion. Section 7 is unnecessary and, to Marty's point, heavy handed. Now would be a great time for Leslie to jump in :-) Or if you don't accept my experiences in this as helpful, feel free to move on with the thread. Frankly, other than the heavy handedness of paragraph 7, I see no brokenness beyond fringe cases. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 4:43:34 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, In the 06/2014 NRPM we had exactly the current policy minus paragraph 7. At that time, we had a policy experience report where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6 for allocations to new MDNs We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum. I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history. I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need. If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7... "7. When an organization declares they are adding a new discrete network site, the new networks shall be allocated: - the minimum allocation size under section 4.2.1.5 - more than the minimum allocation size if the organization can demonstrate additional need using the immediate need criteria (4.2.1.6) - a 3-month supply of address space may be requested if the new MDN can show an applicable demonstrated one-year utilization history." Is that in line with what you are proposing? I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if they believe the organization is not working in good faith) under section 12. Is that about right? __Jason On Tue, Nov 11, 2014 at 7:11 AM, David Huberman > wrote: J- What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't that leave the staff able to issue blocks to new MDNs under the same rules as everyone else in section 4, while at the same time removing the documentation requirement? Thinking out loud. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 3:46:18 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment While I appreciate this discussion, I believe there is a real need to change policy. Previously a new MDN could only qualify under and get an initial allocation sized block. This was extended to include more than the initial allocation sized block under immediate need. I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such is the case when an existing MDN is split. Hence 2014-19. I don't want to get hung up on the proof of deployment text that already exists. Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting. Thank you. __Jason On Tue, Nov 11, 2014 at 12:08 AM, David Huberman > wrote: In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos > wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ 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 rudi.daniel at gmail.com Tue Nov 11 12:18:50 2014 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Tue, 11 Nov 2014 12:18:50 -0500 Subject: [arin-ppml] 2914-19 Message-ID: Agree with Huberman on this one...RIR s are never and hopefully will never be about controlling spam.....if it ain't broken don't fix it. Rudi Daniel ICT consulting 784 430 9235 On Nov 11, 2014 8:44 AM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: 2014-19 and evidence of deployment (David Huberman) > 2. Re: 2014-19 and evidence of deployment (Jason Schiller) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 11 Nov 2014 12:11:45 +0000 > From: David Huberman > To: Jason Schiller > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] 2014-19 and evidence of deployment > Message-ID: > < > b9f16d51e39048a298e57299ea51bc4b at DM2PR03MB398.namprd03.prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > J- > > What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't > that leave the staff able to issue blocks to new MDNs under the same rules > as everyone else in section 4, while at the same time removing the > documentation requirement? > > Thinking out loud. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > ________________________________ > From: Jason Schiller > Sent: Tuesday, November 11, 2014 3:46:18 AM > To: David Huberman > Cc: Martin Hannigan; John Santos; arin-ppml at arin.net > Subject: Re: [arin-ppml] 2014-19 and evidence of deployment > > While I appreciate this discussion, I believe there is a real need to > change policy. > > Previously a new MDN could only qualify under and get an initial > allocation sized block. > > This was extended to include more than the initial allocation sized block > under immediate need. > > I believe there is another case (besides immediate need) where more than > the initial allocation sized block is justified. That is when there is a > demonstrated past 1 year growth history that supports a future looking 3 > month growth of a new MDN. Such is the case when an existing MDN is > split. Hence 2014-19. > > I don't want to get hung up on the proof of deployment text that already > exists. > > Those of you that think this should be changed, please provide suitable > text, and we can run the two policy proposals in parallel. > > If you think this is unnecessary tinkering, then I would expect we will > not rat hole on the pre-existing "proof of deployment" text when discussion > 2014-19 as we did in the previous meeting. > > Thank you. > > > __Jason > > > On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > In my world view, policy should never assume the requestor is lying. The > same should hold true for ARIN staff. > > No one ever mandated ARIN with stopping the scammers. I believe it was > Rob Seastrom who posted here a long time ago and basically said that ARIN > staff are entrusted to do the best job they can in running the registry, > but the community shouldn't have expectations that ARIN staff can figure > out who's lying and who's not. > > But because ARIN got burned by large-scale hijacking in the early 2000s, > it has operated under "trust but verify" ever since. And this fosters the > antagonism towards the registry which I think is wholly avoidable. "Trust > but verify" is a bad way to run an RIR, in my experience. > > I hope we can focus on policy language which always assumes a request is > bona fide, and let's stop worrying about the 1% of requestors who are > lying. That way, network engineers can spend less time dealing with ARIN, > and more time running their networks. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Martin Hannigan > Sent: Monday, November 10, 2014 8:55 PM > To: John Santos > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] 2014-19 and evidence of deployment > > On Mon, Nov 10, 2014 at 6:17 PM, John Santos JOHN at egh.com>> wrote: > > On Mon, 10 Nov 2014, Martin Hannigan wrote: > > > >> > > >> > "7. Upon verification that the organization has shown evidence of > >> > deployment of the new discrete network site, [such as, but not > >> > limited to the > >> > following: a network design showing existing and new discreet > >> > networks and supporting documentation that the proposed design in > >> > in progress such as contracts for new space or power, new equipment > >> > orders, publicly available marketing material describing the > >> > offering in a new location, or some other significant capital > >> > investment in the project,] the new networks shall be > >> > allocated: > >> > > >> > >> Let's go back to the original point I made in the last two PPC and > >> ARIN meetings. How can a company contract for real estate, energy or > >> network without knowing if they had IP addresses to operate their > >> business (in this current environment of v4 scarcity and policy > >> wonkery?)? > > > > Any company with a business plan is taking risks and has to have a > > fall back plan (even if the plan is "pack it in") for any conceivable > > eventuality. You want ARIN to guarantee that they can get IPv4 before > > they've found a site, bought any equipment, signed any contracts with > > suppliers or customers, or even made any public announcements of their > > plans to establish a new site? > > Let me get this straight. So one should have a business plans that > accounts for spending money that may not actually get to generate any > revenue? ARIN has been assigning addresses without this requirement for a > decade plus. The ability to forward look (guarantee) has been shrunk and > now ARIN is targeting MDN for discriminatory policies and removing any > ability to forward look, a normal practice in "business". > The risk of not getting addresses because ARIN is using clueless > requirements is very high, not average. This isn't a simple excercise of > "win some lose some". There are real dollars at stake (whether you operate > a single rack or 1000 racks regardless of how much "power" you > use) and real risks. > > This proposal is best summed up as 'wasteful tinkering'. > > Best, > > -M< > _______________________________________________ > 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 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: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20141111/9467d227/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 11 Nov 2014 07:43:34 -0500 > From: Jason Schiller > To: David Huberman > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] 2014-19 and evidence of deployment > Message-ID: > 9dp7hDdqdZgKTDBN5Yd_zF4TQ at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > David, > > In the 06/2014 NRPM < > https://www.arin.net/policy/archive/nrpm_20140626.pdf> we > had exactly the current policy minus paragraph 7. > > At that time, we had a policy experience report > < > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf > > > where ARIN staff explained 4.5 has criteria for getting additional > addresses for an existing MDN but no criteria for getting addresses for a > new MDN. ARIN staff communicated that they were using only the Immediate > Need 4.2.1.6 for allocations to new MDNs > > We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to > include the minimum. > > I am suggesting further 2014-19 to extend it to also consider a 3 month > supply if there is an applicable supporting 1 year use history. > > I suspect if we struck paragraph 7, ARIN would go back to their previous > practice of only applying immediate need, and looking for connectivity > agreements, and giving a /21 or enough to meet 30 day need. > > If you want to completely remove the proof of deployment, I think you would > still need to keep the second half of paragraph 7... > > "7. When an organization declares they are adding a new discrete network > site, the new networks shall be allocated: > > - the minimum allocation size under section 4.2.1.5 > - more than the minimum allocation size if the organization can > demonstrate additional need using the immediate need criteria (4.2.1.6) > - a 3-month supply of address space may be requested if the new MDN can > show an applicable demonstrated one-year utilization history." > > Is that in line with what you are proposing? > > I assume you would conclude that most organization that declare they have a > new MDN are not committing fraud, and will be using the address within 3 > months, and if not in 3 months or more, ARIN is free to reclaim (if they > believe the organization is not working in good faith) under section 12. > > Is that about right? > > __Jason > > > On Tue, Nov 11, 2014 at 7:11 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > > > J- > > > > What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't > > that leave the staff able to issue blocks to new MDNs under the same > rules > > as everyone else in section 4, while at the same time removing the > > documentation requirement? > > > > Thinking out loud. > > > > David R Huberman > > Microsoft Corporation > > Principal, Global IP Addressing > > ------------------------------ > > *From:* Jason Schiller > > *Sent:* Tuesday, November 11, 2014 3:46:18 AM > > *To:* David Huberman > > *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net > > > > *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment > > > > While I appreciate this discussion, I believe there is a real need to > > change policy. > > > > Previously a new MDN could only qualify under and get an initial > > allocation sized block. > > > > This was extended to include more than the initial allocation sized > > block under immediate need. > > > > I believe there is another case (besides immediate need) where more than > > the initial allocation sized block is justified. That is when there is a > > demonstrated past 1 year growth history that supports a future looking 3 > > month growth of a new MDN. Such is the case when an existing MDN is > > split. Hence 2014-19. > > > > I don't want to get hung up on the proof of deployment text that already > > exists. > > > > Those of you that think this should be changed, please provide suitable > > text, and we can run the two policy proposals in parallel. > > > > If you think this is unnecessary tinkering, then I would expect we will > > not rat hole on the pre-existing "proof of deployment" text when > discussion > > 2014-19 as we did in the previous meeting. > > > > Thank you. > > > > > > __Jason > > > > > > On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < > > David.Huberman at microsoft.com> wrote: > > > >> In my world view, policy should never assume the requestor is lying. > The > >> same should hold true for ARIN staff. > >> > >> No one ever mandated ARIN with stopping the scammers. I believe it was > >> Rob Seastrom who posted here a long time ago and basically said that > ARIN > >> staff are entrusted to do the best job they can in running the registry, > >> but the community shouldn't have expectations that ARIN staff can figure > >> out who's lying and who's not. > >> > >> But because ARIN got burned by large-scale hijacking in the early 2000s, > >> it has operated under "trust but verify" ever since. And this fosters > the > >> antagonism towards the registry which I think is wholly avoidable. > "Trust > >> but verify" is a bad way to run an RIR, in my experience. > >> > >> I hope we can focus on policy language which always assumes a request is > >> bona fide, and let's stop worrying about the 1% of requestors who are > >> lying. That way, network engineers can spend less time dealing with > ARIN, > >> and more time running their networks. > >> > >> David R Huberman > >> Microsoft Corporation > >> Principal, Global IP Addressing > >> > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > >> Behalf Of Martin Hannigan > >> Sent: Monday, November 10, 2014 8:55 PM > >> To: John Santos > >> Cc: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment > >> > >> On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: > >> > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > > >> >> > > >> >> > "7. Upon verification that the organization has shown evidence of > >> >> > deployment of the new discrete network site, [such as, but not > >> >> > limited to the > >> >> > following: a network design showing existing and new discreet > >> >> > networks and supporting documentation that the proposed design in > >> >> > in progress such as contracts for new space or power, new equipment > >> >> > orders, publicly available marketing material describing the > >> >> > offering in a new location, or some other significant capital > >> >> > investment in the project,] the new networks shall be > >> >> > allocated: > >> >> > > >> >> > >> >> Let's go back to the original point I made in the last two PPC and > >> >> ARIN meetings. How can a company contract for real estate, energy or > >> >> network without knowing if they had IP addresses to operate their > >> >> business (in this current environment of v4 scarcity and policy > >> >> wonkery?)? > >> > > >> > Any company with a business plan is taking risks and has to have a > >> > fall back plan (even if the plan is "pack it in") for any conceivable > >> > eventuality. You want ARIN to guarantee that they can get IPv4 before > >> > they've found a site, bought any equipment, signed any contracts with > >> > suppliers or customers, or even made any public announcements of their > >> > plans to establish a new site? > >> > >> Let me get this straight. So one should have a business plans that > >> accounts for spending money that may not actually get to generate any > >> revenue? ARIN has been assigning addresses without this requirement for > a > >> decade plus. The ability to forward look (guarantee) has been shrunk and > >> now ARIN is targeting MDN for discriminatory policies and removing any > >> ability to forward look, a normal practice in "business". > >> The risk of not getting addresses because ARIN is using clueless > >> requirements is very high, not average. This isn't a simple excercise of > >> "win some lose some". There are real dollars at stake (whether you > operate > >> a single rack or 1000 racks regardless of how much "power" you > >> use) and real risks. > >> > >> This proposal is best summed up as 'wasteful tinkering'. > >> > >> Best, > >> > >> -M< > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > >> > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20141111/a537a2f2/attachment.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 113, Issue 14 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Tue Nov 11 12:23:17 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 11 Nov 2014 12:23:17 -0500 Subject: [arin-ppml] 2914-19 In-Reply-To: References: Message-ID: +1 with Mr. Daniel, spot on. Best, -M< On Tue, Nov 11, 2014 at 12:18 PM, Rudolph Daniel wrote: > Agree with Huberman on this one...RIR s are never and hopefully will never > be about controlling spam.....if it ain't broken don't fix it. > > Rudi Daniel > ICT consulting > 784 430 9235 > > On Nov 11, 2014 8:44 AM, wrote: >> >> Send ARIN-PPML mailing list submissions to >> arin-ppml at arin.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.arin.net/mailman/listinfo/arin-ppml >> or, via email, send a message with subject or body 'help' to >> arin-ppml-request at arin.net >> >> You can reach the person managing the list at >> arin-ppml-owner at arin.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of ARIN-PPML digest..." >> >> >> Today's Topics: >> >> 1. Re: 2014-19 and evidence of deployment (David Huberman) >> 2. Re: 2014-19 and evidence of deployment (Jason Schiller) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 11 Nov 2014 12:11:45 +0000 >> From: David Huberman >> To: Jason Schiller >> Cc: "arin-ppml at arin.net" >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> Message-ID: >> >> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> J- >> >> What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't >> that leave the staff able to issue blocks to new MDNs under the same rules >> as everyone else in section 4, while at the same time removing the >> documentation requirement? >> >> Thinking out loud. >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> ________________________________ >> From: Jason Schiller >> Sent: Tuesday, November 11, 2014 3:46:18 AM >> To: David Huberman >> Cc: Martin Hannigan; John Santos; arin-ppml at arin.net >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> >> While I appreciate this discussion, I believe there is a real need to >> change policy. >> >> Previously a new MDN could only qualify under and get an initial >> allocation sized block. >> >> This was extended to include more than the initial allocation sized block >> under immediate need. >> >> I believe there is another case (besides immediate need) where more than >> the initial allocation sized block is justified. That is when there is a >> demonstrated past 1 year growth history that supports a future looking 3 >> month growth of a new MDN. Such is the case when an existing MDN is split. >> Hence 2014-19. >> >> I don't want to get hung up on the proof of deployment text that already >> exists. >> >> Those of you that think this should be changed, please provide suitable >> text, and we can run the two policy proposals in parallel. >> >> If you think this is unnecessary tinkering, then I would expect we will >> not rat hole on the pre-existing "proof of deployment" text when discussion >> 2014-19 as we did in the previous meeting. >> >> Thank you. >> >> >> __Jason >> >> >> On Tue, Nov 11, 2014 at 12:08 AM, David Huberman >> > wrote: >> In my world view, policy should never assume the requestor is lying. The >> same should hold true for ARIN staff. >> >> No one ever mandated ARIN with stopping the scammers. I believe it was >> Rob Seastrom who posted here a long time ago and basically said that ARIN >> staff are entrusted to do the best job they can in running the registry, but >> the community shouldn't have expectations that ARIN staff can figure out >> who's lying and who's not. >> >> But because ARIN got burned by large-scale hijacking in the early 2000s, >> it has operated under "trust but verify" ever since. And this fosters the >> antagonism towards the registry which I think is wholly avoidable. "Trust >> but verify" is a bad way to run an RIR, in my experience. >> >> I hope we can focus on policy language which always assumes a request is >> bona fide, and let's stop worrying about the 1% of requestors who are lying. >> That way, network engineers can spend less time dealing with ARIN, and more >> time running their networks. >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Martin Hannigan >> Sent: Monday, November 10, 2014 8:55 PM >> To: John Santos >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> >> On Mon, Nov 10, 2014 at 6:17 PM, John Santos >> > wrote: >> > On Mon, 10 Nov 2014, Martin Hannigan wrote: >> > >> >> > >> >> > "7. Upon verification that the organization has shown evidence of >> >> > deployment of the new discrete network site, [such as, but not >> >> > limited to the >> >> > following: a network design showing existing and new discreet >> >> > networks and supporting documentation that the proposed design in >> >> > in progress such as contracts for new space or power, new equipment >> >> > orders, publicly available marketing material describing the >> >> > offering in a new location, or some other significant capital >> >> > investment in the project,] the new networks shall be >> >> > allocated: >> >> > >> >> >> >> Let's go back to the original point I made in the last two PPC and >> >> ARIN meetings. How can a company contract for real estate, energy or >> >> network without knowing if they had IP addresses to operate their >> >> business (in this current environment of v4 scarcity and policy >> >> wonkery?)? >> > >> > Any company with a business plan is taking risks and has to have a >> > fall back plan (even if the plan is "pack it in") for any conceivable >> > eventuality. You want ARIN to guarantee that they can get IPv4 before >> > they've found a site, bought any equipment, signed any contracts with >> > suppliers or customers, or even made any public announcements of their >> > plans to establish a new site? >> >> Let me get this straight. So one should have a business plans that >> accounts for spending money that may not actually get to generate any >> revenue? ARIN has been assigning addresses without this requirement for a >> decade plus. The ability to forward look (guarantee) has been shrunk and now >> ARIN is targeting MDN for discriminatory policies and removing any ability >> to forward look, a normal practice in "business". >> The risk of not getting addresses because ARIN is using clueless >> requirements is very high, not average. This isn't a simple excercise of >> "win some lose some". There are real dollars at stake (whether you operate a >> single rack or 1000 racks regardless of how much "power" you >> use) and real risks. >> >> This proposal is best summed up as 'wasteful tinkering'. >> >> Best, >> >> -M< >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any >> issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List >> (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any >> issues. >> >> >> >> -- >> _______________________________________________________ >> Jason >> Schiller|NetOps|jschiller at google.com|571-266-0006 >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 11 Nov 2014 07:43:34 -0500 >> From: Jason Schiller >> To: David Huberman >> Cc: "arin-ppml at arin.net" >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> Message-ID: >> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> David, >> >> In the 06/2014 NRPM >> we >> had exactly the current policy minus paragraph 7. >> >> At that time, we had a policy experience report >> >> >> where ARIN staff explained 4.5 has criteria for getting additional >> addresses for an existing MDN but no criteria for getting addresses for a >> new MDN. ARIN staff communicated that they were using only the Immediate >> Need 4.2.1.6 for allocations to new MDNs >> >> We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs >> to >> include the minimum. >> >> I am suggesting further 2014-19 to extend it to also consider a 3 month >> supply if there is an applicable supporting 1 year use history. >> >> I suspect if we struck paragraph 7, ARIN would go back to their previous >> practice of only applying immediate need, and looking for connectivity >> agreements, and giving a /21 or enough to meet 30 day need. >> >> If you want to completely remove the proof of deployment, I think you >> would >> still need to keep the second half of paragraph 7... >> >> "7. When an organization declares they are adding a new discrete network >> site, the new networks shall be allocated: >> >> - the minimum allocation size under section 4.2.1.5 >> - more than the minimum allocation size if the organization can >> demonstrate additional need using the immediate need criteria (4.2.1.6) >> - a 3-month supply of address space may be requested if the new MDN can >> show an applicable demonstrated one-year utilization history." >> >> Is that in line with what you are proposing? >> >> I assume you would conclude that most organization that declare they have >> a >> new MDN are not committing fraud, and will be using the address within 3 >> months, and if not in 3 months or more, ARIN is free to reclaim (if they >> believe the organization is not working in good faith) under section 12. >> >> Is that about right? >> >> __Jason >> >> >> On Tue, Nov 11, 2014 at 7:11 AM, David Huberman < >> David.Huberman at microsoft.com> wrote: >> >> > J- >> > >> > What if paragraph 7 were struck entirely from existing 4.5 text? >> > Wouldn't >> > that leave the staff able to issue blocks to new MDNs under the same >> > rules >> > as everyone else in section 4, while at the same time removing the >> > documentation requirement? >> > >> > Thinking out loud. >> > >> > David R Huberman >> > Microsoft Corporation >> > Principal, Global IP Addressing >> > ------------------------------ >> > *From:* Jason Schiller >> > *Sent:* Tuesday, November 11, 2014 3:46:18 AM >> > *To:* David Huberman >> > *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net >> > >> > *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment >> > >> > While I appreciate this discussion, I believe there is a real need to >> > change policy. >> > >> > Previously a new MDN could only qualify under and get an initial >> > allocation sized block. >> > >> > This was extended to include more than the initial allocation sized >> > block under immediate need. >> > >> > I believe there is another case (besides immediate need) where more >> > than >> > the initial allocation sized block is justified. That is when there is >> > a >> > demonstrated past 1 year growth history that supports a future looking 3 >> > month growth of a new MDN. Such is the case when an existing MDN is >> > split. Hence 2014-19. >> > >> > I don't want to get hung up on the proof of deployment text that >> > already >> > exists. >> > >> > Those of you that think this should be changed, please provide suitable >> > text, and we can run the two policy proposals in parallel. >> > >> > If you think this is unnecessary tinkering, then I would expect we will >> > not rat hole on the pre-existing "proof of deployment" text when >> > discussion >> > 2014-19 as we did in the previous meeting. >> > >> > Thank you. >> > >> > >> > __Jason >> > >> > >> > On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < >> > David.Huberman at microsoft.com> wrote: >> > >> >> In my world view, policy should never assume the requestor is lying. >> >> The >> >> same should hold true for ARIN staff. >> >> >> >> No one ever mandated ARIN with stopping the scammers. I believe it was >> >> Rob Seastrom who posted here a long time ago and basically said that >> >> ARIN >> >> staff are entrusted to do the best job they can in running the >> >> registry, >> >> but the community shouldn't have expectations that ARIN staff can >> >> figure >> >> out who's lying and who's not. >> >> >> >> But because ARIN got burned by large-scale hijacking in the early >> >> 2000s, >> >> it has operated under "trust but verify" ever since. And this fosters >> >> the >> >> antagonism towards the registry which I think is wholly avoidable. >> >> "Trust >> >> but verify" is a bad way to run an RIR, in my experience. >> >> >> >> I hope we can focus on policy language which always assumes a request >> >> is >> >> bona fide, and let's stop worrying about the 1% of requestors who are >> >> lying. That way, network engineers can spend less time dealing with >> >> ARIN, >> >> and more time running their networks. >> >> >> >> David R Huberman >> >> Microsoft Corporation >> >> Principal, Global IP Addressing >> >> >> >> -----Original Message----- >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> >> Behalf Of Martin Hannigan >> >> Sent: Monday, November 10, 2014 8:55 PM >> >> To: John Santos >> >> Cc: arin-ppml at arin.net >> >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> >> >> >> On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: >> >> > On Mon, 10 Nov 2014, Martin Hannigan wrote: >> >> > >> >> >> > >> >> >> > "7. Upon verification that the organization has shown evidence of >> >> >> > deployment of the new discrete network site, [such as, but not >> >> >> > limited to the >> >> >> > following: a network design showing existing and new discreet >> >> >> > networks and supporting documentation that the proposed design in >> >> >> > in progress such as contracts for new space or power, new >> >> >> > equipment >> >> >> > orders, publicly available marketing material describing the >> >> >> > offering in a new location, or some other significant capital >> >> >> > investment in the project,] the new networks shall be >> >> >> > allocated: >> >> >> > >> >> >> >> >> >> Let's go back to the original point I made in the last two PPC and >> >> >> ARIN meetings. How can a company contract for real estate, energy or >> >> >> network without knowing if they had IP addresses to operate their >> >> >> business (in this current environment of v4 scarcity and policy >> >> >> wonkery?)? >> >> > >> >> > Any company with a business plan is taking risks and has to have a >> >> > fall back plan (even if the plan is "pack it in") for any conceivable >> >> > eventuality. You want ARIN to guarantee that they can get IPv4 >> >> > before >> >> > they've found a site, bought any equipment, signed any contracts with >> >> > suppliers or customers, or even made any public announcements of >> >> > their >> >> > plans to establish a new site? >> >> >> >> Let me get this straight. So one should have a business plans that >> >> accounts for spending money that may not actually get to generate any >> >> revenue? ARIN has been assigning addresses without this requirement for >> >> a >> >> decade plus. The ability to forward look (guarantee) has been shrunk >> >> and >> >> now ARIN is targeting MDN for discriminatory policies and removing any >> >> ability to forward look, a normal practice in "business". >> >> The risk of not getting addresses because ARIN is using clueless >> >> requirements is very high, not average. This isn't a simple excercise >> >> of >> >> "win some lose some". There are real dollars at stake (whether you >> >> operate >> >> a single rack or 1000 racks regardless of how much "power" you >> >> use) and real risks. >> >> >> >> This proposal is best summed up as 'wasteful tinkering'. >> >> >> >> Best, >> >> >> >> -M< >> >> _______________________________________________ >> >> PPML >> >> You are receiving this message because you are subscribed to the ARIN >> >> Public Policy Mailing List (ARIN-PPML at arin.net). >> >> Unsubscribe or manage your mailing list subscription at: >> >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> >> PPML >> >> You are receiving this message because you are subscribed to >> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> >> Unsubscribe or manage your mailing list subscription at: >> >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> Please contact info at arin.net if you experience any issues. >> >> >> > >> > >> > >> > -- >> > _______________________________________________________ >> > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> > >> > >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> >> ------------------------------ >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> End of ARIN-PPML Digest, Vol 113, Issue 14 >> ****************************************** > > > _______________________________________________ > 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 leslien at arin.net Tue Nov 11 16:11:43 2014 From: leslien at arin.net (Leslie Nobile) Date: Tue, 11 Nov 2014 21:11:43 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: Message-ID: Hi David and Jason- I do have some feedback in response to your earlier posts. First let me state that the policy experience report was mainly focused on adding criteria that would require a new MDN site to provide evidence of deployment at the new site, and to ask the community whether current staff practice should be codified into the actual policy text. With the implementation of 2013?6 "Subsequent Allocations for New MDNs", definitive criteria was added that requires the requestor to show some type of evidence of deployment of the new MDN, as well as applying the immediate need policy if more than the minimum allocation is required. These additions to the MDN policy have satisfied staff's concerns with the original policy. To respond to David's request for clarification on how requests for new MDN sites were/are handled, previously a new MDN site was asked to provide evidence of deployment at the new site and would then be issued the minimum allocation size using slow start (as we would with any other initial allocation request). If more than the minimum allocation size was required, the immediate need policy was applied. To be clear, asking for evidence of deployment at the new site and applying immediate need were staff practice, but were not specifically stated in the policy, hence the request for definitive criteria in the policy experience report. In accordance with the latest version of the MDN policy, staff asks for evidence of deployment at the new site and issues the minimum allocation size. If more than the minimum allocation is required, the immediate need policy is applied. To respond to Jason's question regarding splitting a discrete network into two, this would be considered to be two existing discrete networks, not one existing discrete network and one new discrete network, therefore both are issued a three month supply based on demonstrated utilization rate of whatever addresses are held by each existing discrete network. Please let us know if you have additional questions. Regards, Leslie From: Jason Schiller > Date: Tuesday, November 11, 2014 10:48 AM To: David Huberman > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, That would suffice if when an org goes from 4 MDNs to 5 MDNs that ARIN does not treat the newly added region as anew MDN, but my understanding that this is not the case. Leslie, can you comment on this practice as well? It was my understanding from the policy experience report that this is not the case. Thanks, __Jason On Tue, Nov 11, 2014 at 8:38 AM, David Huberman > wrote: You split one site into two sites. The existing addresses go wherever you put them. Your network, your rules. Once a site is 80% and the other condition (50% overall or no /24 free) is met, you ask for more space for that site. That site is not a new. The customers (ISP) or equipment (EU) already existed and the address space already existed. No rule explicitly says staff MUST classify the split sites as new, so staff are free to apply reasoable interpretation to fit the unique situation. Staff should apply regular additional alloc rules for any requests from the split sites. Please note this is beyond a fringe case. We enjoy a fantastic staff who should be free to apply reasonable rules to such a situation, set the new rule as a procedure, and apply consistently as best they are able. Just my opinion. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 5:18:46 AM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, I would love to hear from Leslie on your question, maybe we are trying to solve a non-problem. In the mean time I do have one concern about what you wrote WRT an existing MDN site splitting and being fulfilled under immediate need. Imagine you have MDN1 which grew from nothing to a /16 over the last year. You have just crossed 80% utilization, and want to grow into a new /18 which is a 3 month supply. But the region has gotten too big. So you split it into MDN1 and MDN6. Have the pre-existing customers are in MDN1 and half in MDN6, and half the future looking growth is in MDN1 and half in MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6? 1. MDN6 does not have immediate need. The customers moved there kept the former MDN1 addressing. So you would have to start fresh with a /21, and ramp up to a /19. 2. If you were renumbering the customers in MDN6, you would only qualify for as many as you could address in 30 days (this many not be an issue for ISPs because when you re-allocate or assign the addresses they are in use, but for end-users they actually have to be in service I have personally had an issue qualifying for IPs for an end-user under immediate need when I was asking for as many IPs as I had things to number, but couldn't actually complete numbering them in 30 days). So no in two cases I don't think immediate need (which has an intentionally high bar [to be used in exceptional circumstances] )does not work. __Jason On Tue, Nov 11, 2014 at 7:59 AM, David Huberman > wrote: Something isn't right here. MDN (in basically the 2013 form) existed for 12 years without much of a problem. The language was tinkered a bit for subsequent alloc math, but new sites text wasn't. A new site opening was given: - a /22 or a /20 - dealer's choice since those were the minimums after 2005. Many were issued /20s except for smaller deployments who were happy to take /22s. - more if immediate need justified it. Slow start applies to section 4 requests. So under standard slow start math, you took the /22 or /20, and grow the NEW site with it. Just like an initial alloc to a new ISP. If the site wasn't really new, you could use existing customer counts and apply immediate need. Nothing was broken. A special case like a site split into two is easily handled under the above considerations, isn't it? So ... Either the community has misunderstood Leslie's policy experience report, the report is wrong, or I'm wrong. I stand by my suggestion. Section 7 is unnecessary and, to Marty's point, heavy handed. Now would be a great time for Leslie to jump in :-) Or if you don't accept my experiences in this as helpful, feel free to move on with the thread. Frankly, other than the heavy handedness of paragraph 7, I see no brokenness beyond fringe cases. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 4:43:34 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, In the 06/2014 NRPM we had exactly the current policy minus paragraph 7. At that time, we had a policy experience report where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6 for allocations to new MDNs We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum. I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history. I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need. If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7... "7. When an organization declares they are adding a new discrete network site, the new networks shall be allocated: - the minimum allocation size under section 4.2.1.5 - more than the minimum allocation size if the organization can demonstrate additional need using the immediate need criteria (4.2.1.6) - a 3-month supply of address space may be requested if the new MDN can show an applicable demonstrated one-year utilization history." Is that in line with what you are proposing? I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if they believe the organization is not working in good faith) under section 12. Is that about right? __Jason On Tue, Nov 11, 2014 at 7:11 AM, David Huberman > wrote: J- What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't that leave the staff able to issue blocks to new MDNs under the same rules as everyone else in section 4, while at the same time removing the documentation requirement? Thinking out loud. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 3:46:18 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment While I appreciate this discussion, I believe there is a real need to change policy. Previously a new MDN could only qualify under and get an initial allocation sized block. This was extended to include more than the initial allocation sized block under immediate need. I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such is the case when an existing MDN is split. Hence 2014-19. I don't want to get hung up on the proof of deployment text that already exists. Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting. Thank you. __Jason On Tue, Nov 11, 2014 at 12:08 AM, David Huberman > wrote: In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos > wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ 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 leslien at arin.net Tue Nov 11 18:02:57 2014 From: leslien at arin.net (Leslie Nobile) Date: Tue, 11 Nov 2014 23:02:57 +0000 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: Hi David and Jason- In the scenario Jason describes in his email below when an Org goes from 4 MDNs to 5 MDNs, the 5th MDN would be considered to be a new site. In accordance with NRPM 4.5 (7), the organization would receive the minimum allocation size unless they were able to justify more under the immediate need policy. Regards, Leslie From: David Huberman > Date: Tuesday, November 11, 2014 10:56 AM To: Jason Schiller > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] 2014-19 and evidence of deployment Jason, That's not what I said :-) I addressed what I thought you were presenting - a special case where a network takes one discrete site and splits it. In the regular case, described in your email just now, the new site is new. Slow start applies, minus any immediate need justification. It should get whatever prefix between a /24 and a /20 meets the three month need. It has no customers (or it does and immediate need applies) so why should it get more? This is how it always worked and it generally worked well. It's so easy to get more space for a new discrete site, after all. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 7:48:20 AM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, That would suffice if when an org goes from 4 MDNs to 5 MDNs that ARIN does not treat the newly added region as anew MDN, but my understanding that this is not the case. Leslie, can you comment on this practice as well? It was my understanding from the policy experience report that this is not the case. Thanks, __Jason On Tue, Nov 11, 2014 at 8:38 AM, David Huberman > wrote: You split one site into two sites. The existing addresses go wherever you put them. Your network, your rules. Once a site is 80% and the other condition (50% overall or no /24 free) is met, you ask for more space for that site. That site is not a new. The customers (ISP) or equipment (EU) already existed and the address space already existed. No rule explicitly says staff MUST classify the split sites as new, so staff are free to apply reasoable interpretation to fit the unique situation. Staff should apply regular additional alloc rules for any requests from the split sites. Please note this is beyond a fringe case. We enjoy a fantastic staff who should be free to apply reasonable rules to such a situation, set the new rule as a procedure, and apply consistently as best they are able. Just my opinion. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 5:18:46 AM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, I would love to hear from Leslie on your question, maybe we are trying to solve a non-problem. In the mean time I do have one concern about what you wrote WRT an existing MDN site splitting and being fulfilled under immediate need. Imagine you have MDN1 which grew from nothing to a /16 over the last year. You have just crossed 80% utilization, and want to grow into a new /18 which is a 3 month supply. But the region has gotten too big. So you split it into MDN1 and MDN6. Have the pre-existing customers are in MDN1 and half in MDN6, and half the future looking growth is in MDN1 and half in MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6? 1. MDN6 does not have immediate need. The customers moved there kept the former MDN1 addressing. So you would have to start fresh with a /21, and ramp up to a /19. 2. If you were renumbering the customers in MDN6, you would only qualify for as many as you could address in 30 days (this many not be an issue for ISPs because when you re-allocate or assign the addresses they are in use, but for end-users they actually have to be in service I have personally had an issue qualifying for IPs for an end-user under immediate need when I was asking for as many IPs as I had things to number, but couldn't actually complete numbering them in 30 days). So no in two cases I don't think immediate need (which has an intentionally high bar [to be used in exceptional circumstances] )does not work. __Jason On Tue, Nov 11, 2014 at 7:59 AM, David Huberman > wrote: Something isn't right here. MDN (in basically the 2013 form) existed for 12 years without much of a problem. The language was tinkered a bit for subsequent alloc math, but new sites text wasn't. A new site opening was given: - a /22 or a /20 - dealer's choice since those were the minimums after 2005. Many were issued /20s except for smaller deployments who were happy to take /22s. - more if immediate need justified it. Slow start applies to section 4 requests. So under standard slow start math, you took the /22 or /20, and grow the NEW site with it. Just like an initial alloc to a new ISP. If the site wasn't really new, you could use existing customer counts and apply immediate need. Nothing was broken. A special case like a site split into two is easily handled under the above considerations, isn't it? So ... Either the community has misunderstood Leslie's policy experience report, the report is wrong, or I'm wrong. I stand by my suggestion. Section 7 is unnecessary and, to Marty's point, heavy handed. Now would be a great time for Leslie to jump in :-) Or if you don't accept my experiences in this as helpful, feel free to move on with the thread. Frankly, other than the heavy handedness of paragraph 7, I see no brokenness beyond fringe cases. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 4:43:34 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment David, In the 06/2014 NRPM we had exactly the current policy minus paragraph 7. At that time, we had a policy experience report where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6 for allocations to new MDNs We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum. I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history. I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need. If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7... "7. When an organization declares they are adding a new discrete network site, the new networks shall be allocated: - the minimum allocation size under section 4.2.1.5 - more than the minimum allocation size if the organization can demonstrate additional need using the immediate need criteria (4.2.1.6) - a 3-month supply of address space may be requested if the new MDN can show an applicable demonstrated one-year utilization history." Is that in line with what you are proposing? I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if they believe the organization is not working in good faith) under section 12. Is that about right? __Jason On Tue, Nov 11, 2014 at 7:11 AM, David Huberman > wrote: J- What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't that leave the staff able to issue blocks to new MDNs under the same rules as everyone else in section 4, while at the same time removing the documentation requirement? Thinking out loud. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: Jason Schiller > Sent: Tuesday, November 11, 2014 3:46:18 AM To: David Huberman Cc: Martin Hannigan; John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment While I appreciate this discussion, I believe there is a real need to change policy. Previously a new MDN could only qualify under and get an initial allocation sized block. This was extended to include more than the initial allocation sized block under immediate need. I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such is the case when an existing MDN is split. Hence 2014-19. I don't want to get hung up on the proof of deployment text that already exists. Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting. Thank you. __Jason On Tue, Nov 11, 2014 at 12:08 AM, David Huberman > wrote: In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos > wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ 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 jschiller at google.com Tue Nov 11 19:14:45 2014 From: jschiller at google.com (Jason Schiller) Date: Tue, 11 Nov 2014 19:14:45 -0500 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> <3242cd04bb004ced9e4a8eac1f551564@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: David, I want to apologize for the scenario I proposed. After reading Leslie's comments, and looking back at my text, I realize taking it without the context of your previous email is says something quite different. (And I'm sure it seems like I am trying to intentionally twist your words, which I was not). What I was trying to say, in the most boiled down and generic way is as long as ARIN doesn't automatically see a new region that pops up as a news MDN, when the is some applicable growth history of more than 1 year to be applied. I think splitting is the easiest case to think about (per staff comments this seems not to be a problem), but I think there may be others. Possibly as an example, a company is deploying fiber to residences. They in are 12 markets, each is an MDN for routing reasons, regional Peering, and differences of growth. They entered Washington DC last year, and efficiently used a /16. They are now entering Boston. Boston has nearly the same size (actually slightly smaller) and a similar population (slightly more dense). They have the same commitment to build in Boston as they did in DC, and will pass the same number of residences on the same time line. Can they have a /18? Certainly a company that has deployed fiber to residents in 12 markets now declaring an MDN for their cloud offering would not have an applicable growth history to apply and that should be considered a new MDN. __Jason On Tue, Nov 11, 2014 at 10:56 AM, David Huberman < David.Huberman at microsoft.com> wrote: > Jason, > > That's not what I said :-) I addressed what I thought you were presenting > - a special case where a network takes one discrete site and splits it. > > In the regular case, described in your email just now, the new site is > new. Slow start applies, minus any immediate need justification. It > should get whatever prefix between a /24 and a /20 meets the three month > need. It has no customers (or it does and immediate need applies) so why > should it get more? > > This is how it always worked and it generally worked well. It's so easy > to get more space for a new discrete site, after all. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > ------------------------------ > *From:* Jason Schiller > *Sent:* Tuesday, November 11, 2014 7:48:20 AM > > *To:* David Huberman > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment > > David, > > That would suffice if when an org goes from 4 MDNs to 5 MDNs that ARIN > does not treat the newly added region as anew MDN, but my understanding > that this is not the case. > > Leslie, can you comment on this practice as well? It was my > understanding from the policy experience report that this is not the case. > > Thanks, > > __Jason > > On Tue, Nov 11, 2014 at 8:38 AM, David Huberman < > David.Huberman at microsoft.com> wrote: > >> You split one site into two sites. The existing addresses go wherever >> you put them. Your network, your rules. >> >> Once a site is 80% and the other condition (50% overall or no /24 free) >> is met, you ask for more space for that site. That site is not a new. The >> customers (ISP) or equipment (EU) already existed and the address space >> already existed. No rule explicitly says staff MUST classify the split >> sites as new, so staff are free to apply reasoable interpretation to fit >> the unique situation. >> >> Staff should apply regular additional alloc rules for any requests from >> the split sites. >> >> Please note this is beyond a fringe case. We enjoy a fantastic staff who >> should be free to apply reasonable rules to such a situation, set the new >> rule as a procedure, and apply consistently as best they are able. >> >> Just my opinion. >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> ------------------------------ >> *From:* Jason Schiller >> *Sent:* Tuesday, November 11, 2014 5:18:46 AM >> *To:* David Huberman >> *Cc:* arin-ppml at arin.net >> >> *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment >> >> David, >> >> I would love to hear from Leslie on your question, maybe we are trying >> to solve a non-problem. >> >> In the mean time I do have one concern about what you wrote WRT an >> existing MDN site splitting and being fulfilled under immediate need. >> >> Imagine you have MDN1 which grew from nothing to a /16 over the last >> year. You have just crossed 80% utilization, and want to grow into a new >> /18 which is a 3 month supply. But the region has gotten too big. So you >> split it into MDN1 and MDN6. Have the pre-existing customers are in MDN1 >> and half in MDN6, and half the future looking growth is in MDN1 and half in >> MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 >> over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6? >> >> 1. MDN6 does not have immediate need. The customers moved there kept >> the former MDN1 addressing. So you would have to start fresh with a /21, >> and ramp up to a /19. >> >> 2. If you were renumbering the customers in MDN6, you would only >> qualify for as many as you could address in 30 days (this many not be an >> issue for ISPs because when you re-allocate or assign the addresses they >> are in use, but for end-users they actually have to be in service I have >> personally had an issue qualifying for IPs for an end-user under immediate >> need when I was asking for as many IPs as I had things to number, but >> couldn't actually complete numbering them in 30 days). >> >> So no in two cases I don't think immediate need (which has an >> intentionally high bar [to be used in exceptional circumstances] )does not >> work. >> >> __Jason >> >> >> >> >> >> >> >> >> On Tue, Nov 11, 2014 at 7:59 AM, David Huberman < >> David.Huberman at microsoft.com> wrote: >> >>> Something isn't right here. >>> >>> MDN (in basically the 2013 form) existed for 12 years without much of a >>> problem. The language was tinkered a bit for subsequent alloc math, but >>> new sites text wasn't. A new site opening was given: >>> >>> - a /22 or a /20 - dealer's choice since those were the minimums after >>> 2005. Many were issued /20s except for smaller deployments who were happy >>> to take /22s. >>> >>> - more if immediate need justified it. >>> >>> Slow start applies to section 4 requests. So under standard slow start >>> math, you took the /22 or /20, and grow the NEW site with it. Just like an >>> initial alloc to a new ISP. If the site wasn't really new, you could use >>> existing customer counts and apply immediate need. Nothing was broken. A >>> special case like a site split into two is easily handled under the above >>> considerations, isn't it? >>> >>> So ... Either the community has misunderstood Leslie's policy experience >>> report, the report is wrong, or I'm wrong. >>> >>> I stand by my suggestion. Section 7 is unnecessary and, to Marty's >>> point, heavy handed. >>> >>> Now would be a great time for Leslie to jump in :-) Or if you don't >>> accept my experiences in this as helpful, feel free to move on with the >>> thread. Frankly, other than the heavy handedness of paragraph 7, I see no >>> brokenness beyond fringe cases. >>> >>> David R Huberman >>> Microsoft Corporation >>> Principal, Global IP Addressing >>> ------------------------------ >>> *From:* Jason Schiller >>> *Sent:* Tuesday, November 11, 2014 4:43:34 AM >>> >>> *To:* David Huberman >>> *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net >>> *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment >>> >>> David, >>> >>> In the 06/2014 NRPM >>> we had exactly >>> the current policy minus paragraph 7. >>> >>> At that time, we had a policy experience report >>> >>> where ARIN staff explained 4.5 has criteria for getting additional >>> addresses for an existing MDN but no criteria for getting addresses for a >>> new MDN. ARIN staff communicated that they were using only the Immediate >>> Need 4.2.1.6 for allocations to new MDNs >>> >>> We needed 2014-18 to encourage ARIN to open up the criteria for NEW >>> MDNs to include the minimum. >>> >>> I am suggesting further 2014-19 to extend it to also consider a 3 >>> month supply if there is an applicable supporting 1 year use history. >>> >>> I suspect if we struck paragraph 7, ARIN would go back to their >>> previous practice of only applying immediate need, and looking for >>> connectivity agreements, and giving a /21 or enough to meet 30 day need. >>> >>> If you want to completely remove the proof of deployment, I think you >>> would still need to keep the second half of paragraph 7... >>> >>> "7. When an organization declares they are adding a new discrete >>> network site, the new networks shall be allocated: >>> >>> - the minimum allocation size under section 4.2.1.5 >>> - more than the minimum allocation size if the organization can >>> demonstrate additional need using the immediate need criteria (4.2.1.6) >>> - a 3-month supply of address space may be requested if the new MDN can >>> show an applicable demonstrated one-year utilization history." >>> >>> Is that in line with what you are proposing? >>> >>> I assume you would conclude that most organization that declare they >>> have a new MDN are not committing fraud, and will be using the address >>> within 3 months, and if not in 3 months or more, ARIN is free to reclaim >>> (if they believe the organization is not working in good faith) under >>> section 12. >>> >>> Is that about right? >>> >>> __Jason >>> >>> >>> On Tue, Nov 11, 2014 at 7:11 AM, David Huberman < >>> David.Huberman at microsoft.com> wrote: >>> >>>> J- >>>> >>>> What if paragraph 7 were struck entirely from existing 4.5 text? >>>> Wouldn't that leave the staff able to issue blocks to new MDNs under the >>>> same rules as everyone else in section 4, while at the same time removing >>>> the documentation requirement? >>>> >>>> Thinking out loud. >>>> >>>> David R Huberman >>>> Microsoft Corporation >>>> Principal, Global IP Addressing >>>> ------------------------------ >>>> *From:* Jason Schiller >>>> *Sent:* Tuesday, November 11, 2014 3:46:18 AM >>>> *To:* David Huberman >>>> *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net >>>> >>>> *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment >>>> >>>> While I appreciate this discussion, I believe there is a real need >>>> to change policy. >>>> >>>> Previously a new MDN could only qualify under and get an initial >>>> allocation sized block. >>>> >>>> This was extended to include more than the initial allocation sized >>>> block under immediate need. >>>> >>>> I believe there is another case (besides immediate need) where more >>>> than the initial allocation sized block is justified. That is when there >>>> is a demonstrated past 1 year growth history that supports a future looking >>>> 3 month growth of a new MDN. Such is the case when an existing MDN is >>>> split. Hence 2014-19. >>>> >>>> I don't want to get hung up on the proof of deployment text that >>>> already exists. >>>> >>>> Those of you that think this should be changed, please provide >>>> suitable text, and we can run the two policy proposals in parallel. >>>> >>>> If you think this is unnecessary tinkering, then I would expect we >>>> will not rat hole on the pre-existing "proof of deployment" text when >>>> discussion 2014-19 as we did in the previous meeting. >>>> >>>> Thank you. >>>> >>>> >>>> __Jason >>>> >>>> >>>> On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < >>>> David.Huberman at microsoft.com> wrote: >>>> >>>>> In my world view, policy should never assume the requestor is lying. >>>>> The same should hold true for ARIN staff. >>>>> >>>>> No one ever mandated ARIN with stopping the scammers. I believe it >>>>> was Rob Seastrom who posted here a long time ago and basically said that >>>>> ARIN staff are entrusted to do the best job they can in running the >>>>> registry, but the community shouldn't have expectations that ARIN staff can >>>>> figure out who's lying and who's not. >>>>> >>>>> But because ARIN got burned by large-scale hijacking in the early >>>>> 2000s, it has operated under "trust but verify" ever since. And this >>>>> fosters the antagonism towards the registry which I think is wholly >>>>> avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. >>>>> >>>>> I hope we can focus on policy language which always assumes a request >>>>> is bona fide, and let's stop worrying about the 1% of requestors who are >>>>> lying. That way, network engineers can spend less time dealing with ARIN, >>>>> and more time running their networks. >>>>> >>>>> David R Huberman >>>>> Microsoft Corporation >>>>> Principal, Global IP Addressing >>>>> >>>>> -----Original Message----- >>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>>>> On Behalf Of Martin Hannigan >>>>> Sent: Monday, November 10, 2014 8:55 PM >>>>> To: John Santos >>>>> Cc: arin-ppml at arin.net >>>>> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >>>>> >>>>> On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: >>>>> > On Mon, 10 Nov 2014, Martin Hannigan wrote: >>>>> > >>>>> >> > >>>>> >> > "7. Upon verification that the organization has shown evidence of >>>>> >> > deployment of the new discrete network site, [such as, but not >>>>> >> > limited to the >>>>> >> > following: a network design showing existing and new discreet >>>>> >> > networks and supporting documentation that the proposed design in >>>>> >> > in progress such as contracts for new space or power, new >>>>> equipment >>>>> >> > orders, publicly available marketing material describing the >>>>> >> > offering in a new location, or some other significant capital >>>>> >> > investment in the project,] the new networks shall be >>>>> >> > allocated: >>>>> >> > >>>>> >> >>>>> >> Let's go back to the original point I made in the last two PPC and >>>>> >> ARIN meetings. How can a company contract for real estate, energy or >>>>> >> network without knowing if they had IP addresses to operate their >>>>> >> business (in this current environment of v4 scarcity and policy >>>>> >> wonkery?)? >>>>> > >>>>> > Any company with a business plan is taking risks and has to have a >>>>> > fall back plan (even if the plan is "pack it in") for any conceivable >>>>> > eventuality. You want ARIN to guarantee that they can get IPv4 >>>>> before >>>>> > they've found a site, bought any equipment, signed any contracts with >>>>> > suppliers or customers, or even made any public announcements of >>>>> their >>>>> > plans to establish a new site? >>>>> >>>>> Let me get this straight. So one should have a business plans that >>>>> accounts for spending money that may not actually get to generate any >>>>> revenue? ARIN has been assigning addresses without this requirement for a >>>>> decade plus. The ability to forward look (guarantee) has been shrunk and >>>>> now ARIN is targeting MDN for discriminatory policies and removing any >>>>> ability to forward look, a normal practice in "business". >>>>> The risk of not getting addresses because ARIN is using clueless >>>>> requirements is very high, not average. This isn't a simple excercise of >>>>> "win some lose some". There are real dollars at stake (whether you operate >>>>> a single rack or 1000 racks regardless of how much "power" you >>>>> use) and real risks. >>>>> >>>>> This proposal is best summed up as 'wasteful tinkering'. >>>>> >>>>> Best, >>>>> >>>>> -M< >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to the ARIN >>>>> Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>>> >>>> >>>> >>>> >>>> -- >>>> _______________________________________________________ >>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >>>> >>>> >>> >>> >>> -- >>> _______________________________________________________ >>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >>> >>> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> >> > > > -- > _______________________________________________________ > 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 narten at us.ibm.com Fri Nov 14 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 14 Nov 2014 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201411140553.sAE5r246003774@rotala.raleigh.ibm.com> Total of 45 messages in the last 7 days. script run at: Fri Nov 14 00:53:02 EST 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.56% | 7 | 19.39% | 222868 | jschiller at google.com 8.89% | 4 | 18.16% | 208734 | john at qxccommunications.com 11.11% | 5 | 13.72% | 157761 | david.huberman at microsoft.com 6.67% | 3 | 6.46% | 74280 | matthew at matthew.at 4.44% | 2 | 8.59% | 98765 | leslien at arin.net 8.89% | 4 | 2.81% | 32259 | bill at herrin.us 6.67% | 3 | 3.53% | 40585 | hannigan at gmail.com 4.44% | 2 | 4.90% | 56341 | dogwallah at gmail.com 6.67% | 3 | 2.47% | 28400 | tedm at ipinc.net 2.22% | 1 | 5.50% | 63187 | bononlines at gmail.com 2.22% | 1 | 4.20% | 48323 | rudi.daniel at gmail.com 4.44% | 2 | 1.73% | 19901 | kkargel at polartel.com 2.22% | 1 | 3.85% | 44236 | owen at delong.com 4.44% | 2 | 1.25% | 14362 | michael at linuxmagic.com 2.22% | 1 | 0.86% | 9855 | sryerse at eclipse-networks.com 2.22% | 1 | 0.80% | 9201 | john at egh.com 2.22% | 1 | 0.64% | 7303 | alh-ietf at tndh.net 2.22% | 1 | 0.58% | 6724 | narten at us.ibm.com 2.22% | 1 | 0.56% | 6421 | mcr at sandelman.ca --------+------+--------+----------+------------------------ 100.00% | 45 |100.00% | 1149506 | Total From steve.king at iconaircraft.com Wed Nov 19 12:47:08 2014 From: steve.king at iconaircraft.com (Steve King) Date: Wed, 19 Nov 2014 17:47:08 +0000 Subject: [arin-ppml] Multi-homing justification removed? Message-ID: The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2, appear to have removed the multi-homing justification for a /24 for end users. Previously, the need to multi-home, and proof of contracts with multiple upstream providers, was sufficient to justify a /24 to participate in BGP. For reassignments from ISPs, the language remains in 4.2.3.6. Users can justify a /24 via a requirement to multi-home rather than utilization rate. However this revision appears to leave utilization rate as the only criterion for direct end-user assignments. Was this the intent or possibly an overlooked side effect of the change? Steve King ICON Aircraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjletts at uw.edu Wed Nov 19 13:23:49 2014 From: rjletts at uw.edu (Richard J. Letts) Date: Wed, 19 Nov 2014 18:23:49 +0000 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: Message-ID: I believe the intent was there. orgs that have a justifiable/provable need for a /24 were been restricted by their current/lone provider being unwilling to give them enough address space. Not everyone has the ability to change providers, and if you can't change providers then you certainly would not be able to multihome.. Richard Letts From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steve King Sent: Wednesday, November 19, 2014 9:47 AM To: arin-ppml at arin.net Subject: [arin-ppml] Multi-homing justification removed? The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2, appear to have removed the multi-homing justification for a /24 for end users. Previously, the need to multi-home, and proof of contracts with multiple upstream providers, was sufficient to justify a /24 to participate in BGP. For reassignments from ISPs, the language remains in 4.2.3.6. Users can justify a /24 via a requirement to multi-home rather than utilization rate. However this revision appears to leave utilization rate as the only criterion for direct end-user assignments. Was this the intent or possibly an overlooked side effect of the change? Steve King ICON Aircraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From John at qxccommunications.com Thu Nov 20 00:18:15 2014 From: John at qxccommunications.com (John Von Stein) Date: Thu, 20 Nov 2014 05:18:15 +0000 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: Message-ID: Speaking from recent / current experience, the multi-homing requirement is a bit of a challenge for tweener-sized organizations like QxC. We are too big for underlying fiber carriers to comfortably continue to supply our need for IP addresses but not in the position to carry the financial, technical or operational challenges of multi-homing. This was a very significant cost commitment for QxC and I can imagine this is not achievable for other like-sized ISPs. Granted, we are better off for it now but had I known how much of a financial and technical hurdle this really was then I probably would not have done it. I just needed more IP addresses to continue to grow my biz and would have much rather spent the money and manpower on marketing/sales/customer acquisition. Multi-homing is a nice-to-have luxury that none of my customers are willing to pay for so it is simply a cost of entry to get the IP addresses we need to continue to grow our customer base. As such, I support dropping multi-homing as a prerequisite for an IP allocation. Thank you, John W. Von Stein CEO [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Richard J. Letts Sent: Wednesday, November 19, 2014 1:24 PM To: Steve King; arin-ppml at arin.net Subject: Re: [arin-ppml] Multi-homing justification removed? I believe the intent was there. orgs that have a justifiable/provable need for a /24 were been restricted by their current/lone provider being unwilling to give them enough address space. Not everyone has the ability to change providers, and if you can't change providers then you certainly would not be able to multihome.. Richard Letts From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steve King Sent: Wednesday, November 19, 2014 9:47 AM To: arin-ppml at arin.net Subject: [arin-ppml] Multi-homing justification removed? The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2, appear to have removed the multi-homing justification for a /24 for end users. Previously, the need to multi-home, and proof of contracts with multiple upstream providers, was sufficient to justify a /24 to participate in BGP. For reassignments from ISPs, the language remains in 4.2.3.6. Users can justify a /24 via a requirement to multi-home rather than utilization rate. However this revision appears to leave utilization rate as the only criterion for direct end-user assignments. Was this the intent or possibly an overlooked side effect of the change? Steve King ICON Aircraft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: From hannigan at gmail.com Thu Nov 20 00:20:33 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 19 Nov 2014 22:20:33 -0700 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: Message-ID: Anyone want to debate why there is any multi homing requirement in 2014? Best, -M< > On Nov 19, 2014, at 22:18, John Von Stein wrote: > > Speaking from recent / current experience, the multi-homing requirement is a bit of a challenge for tweener-sized organizations like QxC. We are too big for underlying fiber carriers to comfortably continue to supply our need for IP addresses but not in the position to carry the financial, technical or operational challenges of multi-homing. This was a very significant cost commitment for QxC and I can imagine this is not achievable for other like-sized ISPs. Granted, we are better off for it now but had I known how much of a financial and technical hurdle this really was then I probably would not have done it. I just needed more IP addresses to continue to grow my biz and would have much rather spent the money and manpower on marketing/sales/customer acquisition. Multi-homing is a nice-to-have luxury that none of my customers are willing to pay for so it is simply a cost of entry to get the IP addresses we need to continue to grow our customer base. > > As such, I support dropping multi-homing as a prerequisite for an IP allocation. > > Thank you, > John W. Von Stein > CEO > > > > 102 NE 2nd Street > Suite 136 > Boca Raton, FL 33432 > Office: 561-288-6989 > www.QxCcommunications.com > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Richard J. Letts > Sent: Wednesday, November 19, 2014 1:24 PM > To: Steve King; arin-ppml at arin.net > Subject: Re: [arin-ppml] Multi-homing justification removed? > > I believe the intent was there. > > orgs that have a justifiable/provable need for a /24 were been restricted by their current/lone provider being unwilling to give them enough address space. Not everyone has the ability to change providers, and if you can?t change providers then you certainly would not be able to multihome.. > > Richard Letts > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steve King > Sent: Wednesday, November 19, 2014 9:47 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Multi-homing justification removed? > > The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2, appear to have removed the multi-homing justification for a /24 for end users. Previously, the need to multi-home, and proof of contracts with multiple upstream providers, was sufficient to justify a /24 to participate in BGP. > > For reassignments from ISPs, the language remains in 4.2.3.6. Users can justify a /24 via a requirement to multi-home rather than utilization rate. However this revision appears to leave utilization rate as the only criterion for direct end-user assignments. > > Was this the intent or possibly an overlooked side effect of the change? > > > > Steve King > ICON Aircraft > > _______________________________________________ > 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 athompso at athompso.net Thu Nov 20 02:17:21 2014 From: athompso at athompso.net (Adam Thompson) Date: Thu, 20 Nov 2014 01:17:21 -0600 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: Message-ID: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> Because the lack of multi-homing as a justification makes every IP address user a captive of their initial carrier. Do *you* know anyone who will renumber (short of going out of business altogether)? I think this is an extremely bad idea, tantamount to ARIN "selling out" to ILECs, but further explanation will have to wait until morning when I'm fully awake. -Adam Thompson On November 19, 2014 11:20:33 PM CST, Martin Hannigan wrote: > >Anyone want to debate why there is any multi homing requirement in >2014? > >Best, > >-M< > > > > > >> On Nov 19, 2014, at 22:18, John Von Stein > wrote: >> >> Speaking from recent / current experience, the multi-homing >requirement is a bit of a challenge for tweener-sized organizations >like QxC. We are too big for underlying fiber carriers to comfortably >continue to supply our need for IP addresses but not in the position to >carry the financial, technical or operational challenges of >multi-homing. This was a very significant cost commitment for QxC and >I can imagine this is not achievable for other like-sized ISPs. >Granted, we are better off for it now but had I known how much of a >financial and technical hurdle this really was then I probably would >not have done it. I just needed more IP addresses to continue to grow >my biz and would have much rather spent the money and manpower on >marketing/sales/customer acquisition. Multi-homing is a nice-to-have >luxury that none of my customers are willing to pay for so it is simply >a cost of entry to get the IP addresses we need to continue to grow our >customer base. >> >> As such, I support dropping multi-homing as a prerequisite for an IP >allocation. >> >> Thank you, >> John W. Von Stein >> CEO >> >> >> >> 102 NE 2nd Street >> Suite 136 >> Boca Raton, FL 33432 >> Office: 561-288-6989 >> www.QxCcommunications.com >> >> This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they >are addressed. >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >On Behalf Of Richard J. Letts >> Sent: Wednesday, November 19, 2014 1:24 PM >> To: Steve King; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Multi-homing justification removed? >> >> I believe the intent was there. >> >> orgs that have a justifiable/provable need for a /24 were been >restricted by their current/lone provider being unwilling to give them >enough address space. Not everyone has the ability to change providers, >and if you can?t change providers then you certainly would not be able >to multihome.. >> >> Richard Letts >> >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >On Behalf Of Steve King >> Sent: Wednesday, November 19, 2014 9:47 AM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Multi-homing justification removed? >> >> The changes implemented in ARIN-2014-13, specifically the removal of >4.3.2.2, appear to have removed the multi-homing justification for a >/24 for end users. Previously, the need to multi-home, and proof of >contracts with multiple upstream providers, was sufficient to justify a >/24 to participate in BGP. >> >> For reassignments from ISPs, the language remains in 4.2.3.6. Users >can justify a /24 via a requirement to multi-home rather than >utilization rate. However this revision appears to leave utilization >rate as the only criterion for direct end-user assignments. >> >> Was this the intent or possibly an overlooked side effect of the >change? >> >> > >> >> Steve King >> ICON Aircraft >> >> _______________________________________________ >> 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lar at mwtcorp.net Thu Nov 20 12:19:36 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Thu, 20 Nov 2014 10:19:36 -0700 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> References: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> Message-ID: On Thu, 20 Nov 2014 01:17:21 -0600 Adam Thompson wrote: > Because the lack of multi-homing as a justification makes every IP address user a captive of their initial carrier. Do *you* >know anyone who will renumber (short of going out of business altogether)? Yes, me I have renumbered a /20 4 times. Not fun but not that bad either. Takes about 6 months to work through. > I think this is an extremely bad idea, tantamount to ARIN "selling out" to ILECs, but further explanation will have to wait >until morning when I'm fully awake. > -Adam Thompson > > On November 19, 2014 11:20:33 PM CST, Martin Hannigan wrote: >> >>Anyone want to debate why there is any multi homing requirement in >>2014? >> >>Best, >> >>-M< >> >> >> >> >> >>> On Nov 19, 2014, at 22:18, John Von Stein >> wrote: >>> >>> Speaking from recent / current experience, the multi-homing >>requirement is a bit of a challenge for tweener-sized organizations >>like QxC. We are too big for underlying fiber carriers to comfortably >>continue to supply our need for IP addresses but not in the position to >>carry the financial, technical or operational challenges of >>multi-homing. This was a very significant cost commitment for QxC and >>I can imagine this is not achievable for other like-sized ISPs. >>Granted, we are better off for it now but had I known how much of a >>financial and technical hurdle this really was then I probably would >>not have done it. I just needed more IP addresses to continue to grow >>my biz and would have much rather spent the money and manpower on >>marketing/sales/customer acquisition. Multi-homing is a nice-to-have >>luxury that none of my customers are willing to pay for so it is simply >>a cost of entry to get the IP addresses we need to continue to grow our >>customer base. >>> >>> As such, I support dropping multi-homing as a prerequisite for an IP >>allocation. >>> >>> Thank you, >>> John W. Von Stein >>> CEO >>> >>> >>> >>> 102 NE 2nd Street >>> Suite 136 >>> Boca Raton, FL 33432 >>> Office: 561-288-6989 >>> www.QxCcommunications.com >>> >>> This email and any files transmitted with it are confidential and >>intended solely for the use of the individual or entity to whom they >>are addressed. >>> >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>On Behalf Of Richard J. Letts >>> Sent: Wednesday, November 19, 2014 1:24 PM >>> To: Steve King; arin-ppml at arin.net >>> Subject: Re: [arin-ppml] Multi-homing justification removed? >>> >>> I believe the intent was there. >>> >>> orgs that have a justifiable/provable need for a /24 were been >>restricted by their current/lone provider being unwilling to give them >>enough address space. Not everyone has the ability to change providers, >>and if you can?t change providers then you certainly would not be able >>to multihome.. >>> >>> Richard Letts >>> >>> >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>On Behalf Of Steve King >>> Sent: Wednesday, November 19, 2014 9:47 AM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] Multi-homing justification removed? >>> >>> The changes implemented in ARIN-2014-13, specifically the removal of >>4.3.2.2, appear to have removed the multi-homing justification for a >>/24 for end users. Previously, the need to multi-home, and proof of >>contracts with multiple upstream providers, was sufficient to justify a >>/24 to participate in BGP. >>> >>> For reassignments from ISPs, the language remains in 4.2.3.6. Users >>can justify a /24 via a requirement to multi-home rather than >>utilization rate. However this revision appears to leave utilization >>rate as the only criterion for direct end-user assignments. >>> >>> Was this the intent or possibly an overlooked side effect of the >>change? >>> >>> >> >>> >>> Steve King >>> ICON Aircraft >>> >>> _______________________________________________ >>> 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. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. Larry Ash Senior Network Engineer Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From sethm at rollernet.us Thu Nov 20 12:23:43 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Nov 2014 09:23:43 -0800 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> References: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> Message-ID: <546E239F.60408@rollernet.us> On 11/19/14, 23:17, Adam Thompson wrote: > Because the lack of multi-homing as a justification makes every IP > address user a captive of their initial carrier. Do *you* know anyone > who will renumber (short of going out of business altogether)? I had to renumber out of PA /24's into my current PI space. It was an annoying time sink but not business-breaking. ~Seth From steve.king at iconaircraft.com Thu Nov 20 12:26:20 2014 From: steve.king at iconaircraft.com (Steve King) Date: Thu, 20 Nov 2014 17:26:20 +0000 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: Message-ID: Multi-homing was not a requirement. It was an alternate justification. I can't honestly meet the 50% utilization requirement for a /24, but under the pre-September rules I qualified for a /24 under 4.3.2.2 because I contract with multiple carriers and want to participate in BGP for failover. Now that the language in 4.3.2.2 is gone, my reading is I have to either: a) Lie about my utilization. Not willing to do that. b) Beg for a BGP-transferrable block from a carrier, and even then, deal with the fact that other ISPs are far more likely to aggregate and filter specific routes to large carrier-assigned blocks. I end up with a less reliable failover solution. The policy revision is a significant step backward for me. Maybe I'm enough of an edge case to not matter. But ARIN-2014-13 stated 4.3.2.2 was redundant given the lowered minimum allocation in 4.3.2.1. It was not redundant. It covered a case that I think matters. The worst part is, I'm probably going to end up with two non-BGP transferrable /24s from two carriers (we all know they hand them out like candy with big circuits), so I'll end up burning more IPV4 space than I otherwise would. Steve King ICON Aircraft From: John Von Stein [mailto:John at qxccommunications.com] Sent: Wednesday, November 19, 2014 9:18 PM To: Richard J. Letts; Steve King; arin-ppml at arin.net Subject: RE: Multi-homing justification removed? Speaking from recent / current experience, the multi-homing requirement is a bit of a challenge for tweener-sized organizations like QxC. We are too big for underlying fiber carriers to comfortably continue to supply our need for IP addresses but not in the position to carry the financial, technical or operational challenges of multi-homing. This was a very significant cost commitment for QxC and I can imagine this is not achievable for other like-sized ISPs. Granted, we are better off for it now but had I known how much of a financial and technical hurdle this really was then I probably would not have done it. I just needed more IP addresses to continue to grow my biz and would have much rather spent the money and manpower on marketing/sales/customer acquisition. Multi-homing is a nice-to-have luxury that none of my customers are willing to pay for so it is simply a cost of entry to get the IP addresses we need to continue to grow our customer base. As such, I support dropping multi-homing as a prerequisite for an IP allocation. Thank you, John W. Von Stein CEO [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Richard J. Letts Sent: Wednesday, November 19, 2014 1:24 PM To: Steve King; arin-ppml at arin.net Subject: Re: [arin-ppml] Multi-homing justification removed? I believe the intent was there. orgs that have a justifiable/provable need for a /24 were been restricted by their current/lone provider being unwilling to give them enough address space. Not everyone has the ability to change providers, and if you can't change providers then you certainly would not be able to multihome.. Richard Letts From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steve King Sent: Wednesday, November 19, 2014 9:47 AM To: arin-ppml at arin.net Subject: [arin-ppml] Multi-homing justification removed? The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2, appear to have removed the multi-homing justification for a /24 for end users. Previously, the need to multi-home, and proof of contracts with multiple upstream providers, was sufficient to justify a /24 to participate in BGP. For reassignments from ISPs, the language remains in 4.2.3.6. Users can justify a /24 via a requirement to multi-home rather than utilization rate. However this revision appears to leave utilization rate as the only criterion for direct end-user assignments. Was this the intent or possibly an overlooked side effect of the change? Steve King ICON Aircraft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: From hannigan at gmail.com Thu Nov 20 12:27:34 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 20 Nov 2014 12:27:34 -0500 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> References: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> Message-ID: On Thu, Nov 20, 2014 at 2:17 AM, Adam Thompson wrote: > Because the lack of multi-homing as a justification makes every IP address > user a captive of their initial carrier. Do *you* know anyone who will > renumber (short of going out of business altogether)? Uh, I'm not sure you understand. Or perhaps I misundertsand. I'm saying that you _should not have to be multihomed to receive resources. The requirement could be two _locations_, not two upstream providers. Or better yet, leave in the multi homing requirement but also allow for multiple locations homed to the network. Theoretically, that interpretation is probably valid under the current "policy" regime. But strict interpretation might believe otherwise. The Internet is getting so big these days that the infrastructure that many of us have _does not_ require multihoming each location in a metro, it only requires multiple locations. I may also be missing the point with respect to small providers who are likely to have a single location or a topology that doesn't lend itself to the "cloud" approach. Still, in the age of exhaustion the building case against needs testing "should" also remove multi-homing as a requirement to acquire your own address block so that you do not have to constantly renumber or be captive. Better? -M< From scottleibrand at gmail.com Thu Nov 20 12:42:35 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 20 Nov 2014 09:42:35 -0800 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: Message-ID: Steve, I think your interpretation of 4.3.2.2 is incorrect. That policy section was not the one that authorized the receipt of a (PA) /24 for multihoming. That was, and still is, 4.2.3.6: https://www.arin.net/policy/nrpm.html#four236, which states that "The ISP will then verify the customer's multihoming requirement and may assign the customer a /24, based on this policy." 4.3.2.2 states that the minimum allocation size (from ARIN) for multihomed end users was a /24. However, that did not allow you to get a /24 from ARIN just by becoming multihomed. If you were/are in that situation, you always had to (and still have to) get your /24 from your upstream if you don't meet ARIN's /24 utilizatinon criteria, and demonstrate efficient utilization before getting one from ARIN. If my understanding does not match how policy was implemented by staff prior to implementation of ARIN-2014-13 on 17 September 2014, someone please correct me, but that was the intent of the policy as I understand it. When discussing 2014-13, my sense of the community was that we did not want to authorize receipt of a /24 from ARIN solely based on multihoming, because that could possibly open up a land rush of organizations spun up solely for the purpose of getting a /24 from the free pool, holding it for the requisite time, and then selling it on the transfer market. I personally would be more amenable to considering a policy change to liberalize the requirements for getting a /24 if/when they're available from the transfer market only. -Scott On Thu, Nov 20, 2014 at 9:26 AM, Steve King wrote: > Multi-homing was not a requirement. It was an alternate > justification. I can?t honestly meet the 50% utilization requirement for a > /24, but under the pre-September rules I qualified for a /24 under 4.3.2.2 > because I contract with multiple carriers and want to participate in BGP > for failover. > > > > Now that the language in 4.3.2.2 is gone, my reading is I have to either: > > > > a) Lie about my utilization. Not willing to do that. > > b) Beg for a BGP-transferrable block from a carrier, and even then, > deal with the fact that other ISPs are far more likely to aggregate and > filter specific routes to large carrier-assigned blocks. I end up with a > less reliable failover solution. > > > > The policy revision is a significant step backward for me. Maybe I?m > enough of an edge case to not matter. But ARIN-2014-13 stated 4.3.2.2 was > redundant given the lowered minimum allocation in 4.3.2.1. It was not > redundant. It covered a case that I think matters. > > > > The worst part is, I?m probably going to end up with two non-BGP > transferrable /24s from two carriers (we all know they hand them out like > candy with big circuits), so I?ll end up burning more IPV4 space than I > otherwise would. > > > > > > > > > *Steve King* > > ICON Aircraft > > > > *From:* John Von Stein [mailto:John at qxccommunications.com] > *Sent:* Wednesday, November 19, 2014 9:18 PM > *To:* Richard J. Letts; Steve King; arin-ppml at arin.net > *Subject:* RE: Multi-homing justification removed? > > > > Speaking from recent / current experience, the multi-homing requirement is > a bit of a challenge for tweener-sized organizations like QxC. We are too > big for underlying fiber carriers to comfortably continue to supply our > need for IP addresses but not in the position to carry the financial, > technical or operational challenges of multi-homing. This was a very > significant cost commitment for QxC and I can imagine this is not > achievable for other like-sized ISPs. Granted, we are better off for it > now but had I known how much of a financial and technical hurdle this > really was then I probably would not have done it. I just needed more IP > addresses to continue to grow my biz and would have much rather spent the > money and manpower on marketing/sales/customer acquisition. Multi-homing > is a nice-to-have luxury that none of my customers are willing to pay for > so it is simply a cost of entry to get the IP addresses we need to continue > to grow our customer base. > > > > As such, I support dropping multi-homing as a prerequisite for an IP > allocation. > > > > Thank you, > > John W. Von Stein > > CEO > > > > [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] > > > > 102 NE 2nd Street > > Suite 136 > > Boca Raton, FL 33432 > > Office: 561-288-6989 > > www.QxCcommunications.com > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *Richard J. Letts > *Sent:* Wednesday, November 19, 2014 1:24 PM > *To:* Steve King; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Multi-homing justification removed? > > > > I believe the intent was there. > > > > orgs that have a justifiable/provable need for a /24 were been restricted > by their current/lone provider being unwilling to give them enough address > space. Not everyone has the ability to change providers, and if you can?t > change providers then you certainly would not be able to multihome.. > > > > *Richard Letts* > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *Steve King > *Sent:* Wednesday, November 19, 2014 9:47 AM > *To:* arin-ppml at arin.net > *Subject:* [arin-ppml] Multi-homing justification removed? > > > > The changes implemented in ARIN-2014-13, specifically the removal of > 4.3.2.2, appear to have removed the multi-homing justification for a /24 > for end users. Previously, the need to multi-home, and proof of contracts > with multiple upstream providers, was sufficient to justify a /24 to > participate in BGP. > > > > For reassignments from ISPs, the language remains in 4.2.3.6. Users can > justify a /24 via a requirement to multi-home rather than utilization > rate. However this revision appears to leave utilization rate as the only > criterion for direct end-user assignments. > > > > Was this the intent or possibly an overlooked side effect of the change? > > > > > > > > > *Steve King* > > ICON Aircraft > > > > _______________________________________________ > 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: 2999 bytes Desc: not available URL: From info at arin.net Thu Nov 20 13:05:13 2014 From: info at arin.net (ARIN) Date: Thu, 20 Nov 2014 13:05:13 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised Message-ID: <546E2D59.4050407@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: 19 October 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: Replace Section 4.2.4.1 ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers. Replace Section 4.3.6.1 End-users must have efficiently utilized all assignments, in aggregate, to at least 80% and at least 50% of every assignment in order to receive additional space, and must provide ARIN with utilization details. Comments: a. Timetable for implementation: Immediate b. From jschiller at google.com Thu Nov 20 13:18:13 2014 From: jschiller at google.com (Jason Schiller) Date: Thu, 20 Nov 2014 13:18:13 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <546E2D59.4050407@arin.net> References: <546E2D59.4050407@arin.net> Message-ID: Can ARIN staff please clarify current operating procedures and how they would change under this proposal. My understanding is that is an ISP assigns a subnet to an end-user customer, and that end-site customer has a host count that exceeds 50% then the ISP gets to count that customer assignment as 100% used toward aggregate of each aggregate allocation. If this policy passed would the ISP still be able to count subnets assigned to customers which host counts over 50% as 100% utilized towards total utilization? Same question in the case of end-sites. If an end-user has a justifiable reason to subnet the space, and each of the subnets are above 50% utilization, then are those actual utilization counted towards the total utilization, or does the end-user get to count subnets greater than 50% full as completely utilized towards total utilization? __Jason On Thu, Nov 20, 2014 at 1:05 PM, ARIN wrote: > 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: 19 October 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: > > Replace Section 4.2.4.1 > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% and at least 50% of every allocation in order to receive > additional space. This includes all space reassigned to their customers. > > Replace Section 4.3.6.1 > > End-users must have efficiently utilized all assignments, in aggregate, to > at least 80% and at least 50% of every assignment 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Thu Nov 20 13:25:20 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 20 Nov 2014 10:25:20 -0800 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <546E2D59.4050407@arin.net> References: <546E2D59.4050407@arin.net> Message-ID: <546E3210.5010602@linuxmagic.com> On 14-11-20 10:05 AM, ARIN wrote: > Policy statement: > > Replace Section 4.2.4.1 > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% and at least 50% of every allocation in order to receive > additional space. This includes all space reassigned to their customers. > > Replace Section 4.3.6.1 > > End-users must have efficiently utilized all assignments, in aggregate, > to at least 80% and at least 50% of every assignment in order to receive > additional space, and must provide ARIN with utilization details. Sounds good, but suggest it get extended slightly.. End-users must have efficiently utilized all assignments, in aggregate, to at least 80% and at least 50% of every assignment in order to receive additional space, must provide ARIN with utilization details, and have correct information in WHOIS directory via SWIP or use of an RWhois server (Section 4.2.3.7 and Section 3.2) and has responded to a recent Annual Whois POC Verificaiton (Section 3.6) This will help aid ARIN in ensuring information is up to date, for their own purposes. Someone else probably can suggest better legal wording and/or phrasing, but you get the drift.. -- "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 bill at herrin.us Thu Nov 20 13:33:16 2014 From: bill at herrin.us (William Herrin) Date: Thu, 20 Nov 2014 13:33:16 -0500 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: Message-ID: On Wed, Nov 19, 2014 at 12:47 PM, Steve King wrote: > The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2, > appear to have removed the multi-homing justification for a /24 for end users. > Previously, the need to multi-home, and proof of contracts with multiple upstream > providers, was sufficient to justify a /24 to participate in BGP. Hi Steve, IIRC, multihoming was a justification for receiving a /24 instead of a /22, meaning that multihomed users could ask for less space. Single-homed users needed to be large enough to justify a /22 before they could get space from ARIN. Multihomed users still had to justify a /24 the regular way -- with utilization. Getting a /24 solely because of multihoming only applied to getting space from an ISP, not getting space directly from ARIN. As it still does. > Was this the intent or possibly an overlooked side effect of the change? Now that you can get a /24 regardless of whether you're multihomed, the multihoming language was removed. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Nov 20 13:43:05 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 20 Nov 2014 13:43:05 -0500 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: References: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> Message-ID: <00C813C911C04137BEFCDB6D7A59DFF8@MPC> Still, in the age of exhaustion the building case against needs testing "should" also remove multi-homing as a requirement to acquire your own address block so that you do not have to constantly renumber or be captive. -Martin Hannigan I personally would be more amenable to considering a policy change to liberalize the requirements for getting a /24 if/when they're available from the transfer market only.-Scott Hi Martin and Scott, Just to present the reminder that 2014-14 would answer here, as it would provide the ability for entities in the sorts of situations being discussed to purchase up to a /16 without a needs test on the transfer market. 2014-14 presents a relief valve for ARIN members facing this issue, and many other known and unforeseeable issues. Transitioning to a paid market for addresses can only be expected to create turbulent conditions. It would be nice for members to know they have a outlet for exigent circumstances built into policy. Regards, Mike . From bill at herrin.us Thu Nov 20 13:50:05 2014 From: bill at herrin.us (William Herrin) Date: Thu, 20 Nov 2014 13:50:05 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <546E3210.5010602@linuxmagic.com> References: <546E2D59.4050407@arin.net> <546E3210.5010602@linuxmagic.com> Message-ID: On Thu, Nov 20, 2014 at 1:25 PM, Michael Peddemors wrote: > Sounds good, but suggest it get extended slightly.. > > End-users must have efficiently utilized all assignments, in aggregate, > to at least 80% and at least 50% of every assignment in order to > receive additional space, must provide ARIN with utilization > details, and have correct information in WHOIS directory via > SWIP or use of an RWhois server (Section 4.2.3.7 and Section > 3.2) and has responded to a recent Annual Whois POC Verificaiton (Section 3.6) > > This will help aid ARIN in ensuring information is up to date, for their own purposes. Hi Michael, You're kind of straying from policy language to business process language. The idea is that policy should tell ARIN -what- data it should require while business process tells ARIN -how- to collect and maintain that data. (Yes, 3.6.1 is badly written in that respect.) So, you'd want words along the lines of, "must have published accurate and complete utilization information and points of contact." Also, throwing the language in this way could muddy things. Accurate publication is conceptually separate from amount of utilization. 4.2.4 has multiple subheadings, each with a distinct requirement for ISPs requesting additional space. Consider whether this requirement would belong in a separate subheading and, if it does, whether adding that separate subheading would be better pursued in a separate policy proposal or if it really needs to be attached to this one. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Thu Nov 20 14:04:59 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 20 Nov 2014 11:04:59 -0800 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: References: <546E2D59.4050407@arin.net> <546E3210.5010602@linuxmagic.com> Message-ID: <546E3B5B.6070509@linuxmagic.com> On 14-11-20 10:50 AM, William Herrin wrote: > On Thu, Nov 20, 2014 at 1:25 PM, Michael Peddemors > > wrote: > > Sounds good, but suggest it get extended slightly.. > > > > End-users must have efficiently utilized all assignments, in aggregate, > > to at least 80% and at least 50% of every assignment in order to > > receive additional space, must provide ARIN with utilization > > details, and have correct information in WHOIS directory via > > SWIP or use of an RWhois server (Section 4.2.3.7 and Section > > 3.2) and has responded to a recent Annual Whois POC Verificaiton > (Section 3.6) > > > > This will help aid ARIN in ensuring information is up to date, for > their own purposes. > > Hi Michael, > > You're kind of straying from policy language to business process > language. The idea is that policy should tell ARIN -what- data it should > require while business process tells ARIN -how- to collect and maintain > that data. (Yes, 3.6.1 is badly written in that respect.) > > So, you'd want words along the lines of, "must have published accurate > and complete utilization information and points of contact." > > Also, throwing the language in this way could muddy things. Accurate > publication is conceptually separate from amount of utilization. 4.2.4 > has multiple subheadings, each with a distinct requirement for ISPs > requesting additional space. Consider whether this requirement would > belong in a separate subheading and, if it does, whether adding that > separate subheading would be better pursued in a separate policy > proposal or if it really needs to be attached to this one. > > Regards, > Bill Herrin > I get your point, but while "Accurate publication is conceptually separate from amount of utilization" this is related to getting new IP Space, and I don't see anywhere explicit language to say you don't get more space, unless your current space is operated properly according to policy, especially as it pertains to accurate whois and contact information, for both the parent and the delegated space.. Speaking with ARIN a few times on this issue, one of the complaints staff have is to even get POC data right.. (hehe.. to send the bill even) and if we can add language that helps enable ARIN to operate better, and to support the language elsewhere in the policies, maybe that data will get more accurate. It also helps support future enforcement measures, if ARIN ever gets that mandate.. right now, they take reports of non-functioning rwhois, or incorrect information, but all it is is a note on their records. Explicitly adding the language will allow ARIN staff to point to a policy during application(s) and say "the policy says you have to fix this before you get new 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 rbf+arin-ppml at panix.com Thu Nov 20 20:52:33 2014 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Thu, 20 Nov 2014 19:52:33 -0600 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate - revised In-Reply-To: <546E2D59.4050407@arin.net> References: <546E2D59.4050407@arin.net> Message-ID: <20141121015233.GA25479@panix.com> On Thu, Nov 20, 2014 at 01:05:13PM -0500, ARIN wrote: > 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 Change Utilization Requirements from > last-allocation to total-aggregate > > Policy statement: > > Replace Section 4.2.4.1 > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% and at least 50% of every allocation in order to receive > additional space. This includes all space reassigned to their customers. > > Replace Section 4.3.6.1 > > End-users must have efficiently utilized all assignments, in aggregate, to > at least 80% and at least 50% of every assignment in order to receive > additional space, and must provide ARIN with utilization details. Strongly support. Whether or not an organization is justified in requesting more address space should not vary based on which parts of their existing space they have allocated. The current policy creates perverse incentives to, for example, spend engineering resources renumbering subnets from one block to another just to support justification of additional space, or to make all new customer assignments out of the newly issued block even with sound engineering practice (for example, reasonable internal aggregation) would support using other blocks. I believe the 50% requirement added to the policy proposal adequately addresses the concern that some providers or end users would make a request and receive an allocation or assignment, and then immediately be eligible to make another request with the same justification as the first request. (Of course, it creates the same type of perverse incentives as the current policy, but to a much lesser degree I also note that under current policy, organizations which remain 80% utilized in aggregate after receiving an allocation could rearrange their existing usage to achieve 80% utilization across all allocations, and then qualify for additional space without having made any additional usage. While doing so would not be practical for all organizations, some organizations would have enough space utilized in dynamic pools that such a rearrangement would be doable in a short amount of time. (Also: Oppose any attempt to make this about more than utilization requirements. I agree that better WHOIS data is a worthwhile goal, as are many other things, but they should be addressed by a separate policy proposal, so that the community can evaluate the merits of each change independently.) -- Brett From frnkblk at iname.com Thu Nov 20 22:39:36 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 20 Nov 2014 21:39:36 -0600 Subject: [arin-ppml] 2014-19 and evidence of deployment In-Reply-To: <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> References: <1141110173410.341A-100000@Ives.egh.com> <5567d560e8194f5f84a84ec512ade14a@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <004701d0053c$c5824550$5086cff0$@iname.com> Do we have data that suggests that only 1% of the requests (or the resources those requests represent) are fraudulent? My guess is that it's higher. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Monday, November 10, 2014 11:09 PM To: Martin Hannigan; John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff. No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations that ARIN staff can figure out who's lying and who's not. But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an RIR, in my experience. I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks. David R Huberman Microsoft Corporation Principal, Global IP Addressing -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, November 10, 2014 8:55 PM To: John Santos Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2014-19 and evidence of deployment On Mon, Nov 10, 2014 at 6:17 PM, John Santos wrote: > On Mon, 10 Nov 2014, Martin Hannigan wrote: > >> > >> > "7. Upon verification that the organization has shown evidence of >> > deployment of the new discrete network site, [such as, but not >> > limited to the >> > following: a network design showing existing and new discreet >> > networks and supporting documentation that the proposed design in >> > in progress such as contracts for new space or power, new equipment >> > orders, publicly available marketing material describing the >> > offering in a new location, or some other significant capital >> > investment in the project,] the new networks shall be >> > allocated: >> > >> >> Let's go back to the original point I made in the last two PPC and >> ARIN meetings. How can a company contract for real estate, energy or >> network without knowing if they had IP addresses to operate their >> business (in this current environment of v4 scarcity and policy >> wonkery?)? > > Any company with a business plan is taking risks and has to have a > fall back plan (even if the plan is "pack it in") for any conceivable > eventuality. You want ARIN to guarantee that they can get IPv4 before > they've found a site, bought any equipment, signed any contracts with > suppliers or customers, or even made any public announcements of their > plans to establish a new site? Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee) has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business". The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how much "power" you use) and real risks. This proposal is best summed up as 'wasteful tinkering'. Best, -M< _______________________________________________ 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 narten at us.ibm.com Fri Nov 21 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 21 Nov 2014 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201411210553.sAL5r263026711@rotala.raleigh.ibm.com> Total of 20 messages in the last 7 days. script run at: Fri Nov 21 00:53:02 EST 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.00% | 2 | 16.22% | 44838 | steve.king at iconaircraft.com 10.00% | 2 | 10.51% | 29037 | hannigan at gmail.com 5.00% | 1 | 12.51% | 34574 | scottleibrand at gmail.com 10.00% | 2 | 6.66% | 18419 | bill at herrin.us 10.00% | 2 | 5.68% | 15689 | michael at linuxmagic.com 5.00% | 1 | 8.87% | 24503 | john at qxccommunications.com 5.00% | 1 | 8.21% | 22690 | athompso at athompso.net 5.00% | 1 | 5.90% | 16293 | jschiller at google.com 5.00% | 1 | 5.68% | 15702 | rjletts at uw.edu 5.00% | 1 | 3.86% | 10658 | lar at mwtcorp.net 5.00% | 1 | 3.68% | 10164 | frnkblk at iname.com 5.00% | 1 | 2.69% | 7436 | narten at us.ibm.com 5.00% | 1 | 2.63% | 7259 | rbf+arin-ppml at panix.com 5.00% | 1 | 2.54% | 7014 | info at arin.net 5.00% | 1 | 2.26% | 6243 | mike at iptrading.com 5.00% | 1 | 2.11% | 5841 | sethm at rollernet.us --------+------+--------+----------+------------------------ 100.00% | 20 |100.00% | 276360 | Total From athompso at athompso.net Fri Nov 21 02:28:24 2014 From: athompso at athompso.net (Adam Thompson) Date: Fri, 21 Nov 2014 01:28:24 -0600 Subject: [arin-ppml] Multi-homing justification removed? In-Reply-To: <00C813C911C04137BEFCDB6D7A59DFF8@MPC> References: <895F96C1-473F-44DF-AC3E-080FCE028E24@athompso.net> <00C813C911C04137BEFCDB6D7A59DFF8@MPC> Message-ID: <546EE998.8070108@athompso.net> On 14-11-20 12:43 PM, Mike Burns wrote: > Still, in the age of exhaustion the > building case against needs testing "should" also remove multi-homing > as a requirement to acquire your own address block so that you do not > have to constantly renumber or be captive. -Martin Hannigan > > I personally would be more amenable to considering a policy change to > liberalize the requirements for getting a /24 if/when they're > available from the transfer market only.-Scott > > > > Hi Martin and Scott, > > Just to present the reminder that 2014-14 would answer here, as it > would provide the ability for entities in the sorts of situations > being discussed to purchase up to a /16 without a needs test on the > transfer market. > > 2014-14 presents a relief valve for ARIN members facing this issue, > and many other known and unforeseeable issues. > Transitioning to a paid market for addresses can only be expected to > create turbulent conditions. > It would be nice for members to know they have a outlet for exigent > circumstances built into policy. > > Regards, > Mike My understanding, and the premise on which I acquired a /24, was that multihoming was, in and of itself, sufficient justification for a direct assignment. It's a multi-stage problem, IMHO: 1a) you can't get a /24 from your upstream if you can't justify the usage [although upstreams are often lax on this rule] 1b) you can't get anything smaller than a /24 from ARIN 2) you can't successfully/usefully advertise or use anything smaller than a /24 3) you typically can't successfully/usefully advertise ISP A's address space (even when correctly delegated) via ISP B. Reasons for this vary from technical (route aggregation &| filtering in large transit networks) to contractual (thou shalt not...) to incompetent (ISP B insists this isn't possible). You'd think the incompetence-based reasons would weed themselves out over time, but Canada doesn't exactly have a thriving competitive marketplace for transport. I haven't had time to review the policy (old and new), so I may be basing all on incorrect assumptions. Hoping to make time to re-read both current and past policy on Friday. -- -Adam Thompson athompso at athompso.net Cell: +1 204 291-7950 Fax: +1 204 489-6515 From info at arin.net Tue Nov 25 15:34:58 2014 From: info at arin.net (ARIN) Date: Tue, 25 Nov 2014 15:34:58 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - November 2014 Message-ID: <5474E7F2.60606@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 20 November 2014. The AC recommended the following to the ARIN Board for adoption: Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements The AC accepted the following Proposals as a Draft Policies: ARIN-prop-213 Modification to CI Pool Size per Section 4.4 ARIN-prop-214 Removal of Minimum in Section 4.10 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-17: Change Utilization Requirements from last-allocation to total-aggregate Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Nov 25 15:35:15 2014 From: info at arin.net (ARIN) Date: Tue, 25 Nov 2014 15:35:15 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 Message-ID: <5474E803.9020504@arin.net> On 20 November 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-213 Modification to CI Pool Size per Section 4.4" as a Draft Policy. Draft Policy ARIN-2014-21 is below and can be found at: https://www.arin.net/policy/proposals/2014_21.html You are encouraged to discuss the merits and your concerns of Draft Policy 2014-21 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-21 Modification to CI Pool Size per Section 4.4 Date: 25 November 2014 Problem Statement: At the time that this section of policy was written, IXP growth in North America was stagnant. Efforts of late have increased significantly within the IXP standards and other communities to improve critical infrastructure in North America. This effort is paying dividends and we project that a /16 will not be enough to continue to improve global interconnect conditions and support needed IXP CI infrastructure. Policy statement: Change to text in section 4.4 Micro Allocations: Current text: ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. Proposed text to replace current text entirely: ARIN will place an equivalent of a /15 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. Timetable for implementation: Immediate From info at arin.net Tue Nov 25 15:35:29 2014 From: info at arin.net (ARIN) Date: Tue, 25 Nov 2014 15:35:29 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10 Message-ID: <5474E811.40500@arin.net> On 20 November 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-214 Removal of Minimum in Section 4.10" as a Draft Policy. Draft Policy ARIN-2014-22 is below and can be found at: https://www.arin.net/policy/proposals/2014_22.html You are encouraged to discuss the merits and your concerns of Draft Policy 2014-22 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-22 Removal of Minimum in Section 4.10 Date: 25 November 2014 Problem Statement: The current section 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment creates an issue where a small new organization that requires an IPv4 allocation or assignment would potentially receive a block that today would be unroutable and therefore unusable for it intended purposes. Policy statement: Change "This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block." To "This block will be subject to an allocation of /24. ARIN should use sparse allocation when possible within that /10 block." Timetable for implementation: Immediate From narten at us.ibm.com Fri Nov 28 00:53:04 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 28 Nov 2014 00:53:04 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201411280553.sAS5r4he009466@rotala.raleigh.ibm.com> Total of 5 messages in the last 7 days. script run at: Fri Nov 28 00:53:03 EST 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 60.00% | 3 | 55.51% | 18354 | info at arin.net 20.00% | 1 | 22.60% | 7473 | athompso at athompso.net 20.00% | 1 | 21.89% | 7240 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 5 |100.00% | 33067 | Total