From bill at herrin.us Fri Jan 1 02:17:24 2010 From: bill at herrin.us (William Herrin) Date: Fri, 1 Jan 2010 02:17:24 -0500 Subject: [arin-ppml] Not petitioning proposal 103 Message-ID: <3c3e3fca0912312317x3b2ce7bma6ad61201b0316@mail.gmail.com> Happy New Year, On consideration, I won't petition the AC's abandonment of proposal 103. I accept the AC's conclusion that there is more that can be done in the process before pushing a formal proposal. I'd like to thank each of you who committed privately to support such a petition. Although we could have forced it forward, I think I spy some potentially more productive avenues for advancement. Rest assured: I have no intention of dropping the matter. I enthusiastically support proposal 106. Scott incorporated those parts of 103's improvements that do not depend on abandoning needs-based allocation. I think he did a good job and I think the result would significant;y improve ARIN's IPv6 address management process. I'll be very disappointed if it is not accepted to the AC's docket for formal discussion and presentation at the meeting. Proposal 103 raise another issue that I believe we should address as a community: should ARIN be the gatekeeper to Internet routing policy? In most of the time since ARIN's inception, the question has been moot: network operators depended on ARIN to act as a check on routing table growth lest the Internet collapse. With IPv4, no credible method has been proposed for controlling route table growth without RIR policy enforcement. It's a bona fide "tragedy of the commons" problem. Proposal 103 offered a credible way to maintain control of IPv6 route table growth without requiring ARIN to act as the gatekeeper to Internet routing in North America. Now that we know there's one way, we may quickly discover that there are more. So, now that we actually have a choice, should ARIN be set IPv6 Internet routing policy for North America? Or would we all be better off letting the ISPs individually decide for themselves? I'd like to see further discussion, particularly about the "how." Proposal 103 did it with ARIN fees used as a proxy to classify the network registrant's perception of the value of his system. What other methods might work? I'd also like to see all of this presented at this year's meetings. Judging from the response to proposal 103, the topic has wide enough interest and support that My choice comes with two caveats: 1. Although Scott's proposal does not remove ARIN from the position of setting Internet routing policy for North America, it does incorporate many other valuable improvements from proposal 103. I believe that 106's adoption would substantially improve ARIN's IPv6 address allocation policy and practices. 2. I would like to solicit the AC's assistance both in exploring how to disentangle ARIN from setting IPv6 routing policy and determining the breadth of support for such a radical departure from ARIN's current practice. Since its inception, ARIN has largely set IPv4 routing policy for North America. It does so by determining (through "need-based" criteria) who is and is not qualified to obtain DFZ-routeable IP addresses. ARIN has been thwarted only to a minor extent by the presence and action of the pre-ARIN "legacy registrants." Such a top-down and somewhat unintentional routing policy has significant drawbacks, particularly as it pertains to innovative use by small organizations. This may not be the most healthy way to build Internet routing policy. Proposal 103 was the first time I've seen a credible alternative to ARIN-set routing policy given serious consideration. The comments about proposal 103 suggest that there may be wide support for leaving routing policy to the network operators instead of ARIN. In addition to discussion here on PPML, I'd like to see ideas for bottom-up operator-implemented routing policy presented at ARIN's 2009 public meetings and discussed with the wider policy community there along with any frameworks for actually making it happen. I'd also like to see that wider community solicited for feedback: was this just a blip on the PPML or is it something many of them want too? Given the radical nature of the idea and the detail-oriented nature of potential implementation frameworks, I believe such a presentation is beyond the scope of the open policy hour. Short of advancing it as implemented in a formal policy proposal, how do we get it added to the meeting agendas? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Jan 1 02:34:05 2010 From: bill at herrin.us (William Herrin) Date: Fri, 1 Jan 2010 02:34:05 -0500 Subject: [arin-ppml] Not petitioning proposal 103 In-Reply-To: <3c3e3fca0912312317x3b2ce7bma6ad61201b0316@mail.gmail.com> References: <3c3e3fca0912312317x3b2ce7bma6ad61201b0316@mail.gmail.com> Message-ID: <3c3e3fca0912312334q6cb42e84qab0b3af14afde7b9@mail.gmail.com> Apparently I need to enable "mail goggles" after all. Please disregard my last message and let's try that again... On consideration, I won't petition the AC's abandonment of proposal 103. I accept the AC's conclusion that there is more that can be done in the process before pushing a formal proposal. I enthusiastically support proposal 106. Scott incorporated those parts of 103's improvements that do not depend on abandoning needs-based allocation. I think he did a good job and I think the result would significantly improve ARIN's IPv6 address management process. I'll be very disappointed if 106 is not accepted to the AC's docket for formal discussion and presentation. Proposal 103 raised another issue that I believe we should address as a community: should ARIN be the gatekeeper to Internet routing policy? In most of the time since ARIN's inception, the question has been moot: network operators depend on ARIN to act as a check on IPv4 routing table growth lest the Internet collapse. With IPv4, no credible method has been proposed for controlling route table growth without RIR policy enforcement. It's a bona fide "tragedy of the commons" problem. Proposal 103 offered a credible way to maintain control of IPv6 route table growth without requiring ARIN to act as the gatekeeper to Internet routing in North America. Perhaps not an optimal way, but at least a credible one. Now that we know there's one way, we may discover that there are more. So, now that we actually have a choice, should ARIN be set IPv6 Internet routing policy for North America? Or would we all be better off letting the ISPs reach a functional consensus that isn't tied to ARIN's operation? I'd like to see further discussion, particularly about the "how." Proposal 103 did it with ARIN fees used as a proxy to classify the network registrant's perception of the value of his system. What other methods might work? I'd also like to see all of this presented at this year's meetings. Judging from the response to proposal 103, moving ARIN out of the routing policy game has wide enough interest and support to merit presentation. Open policy hour doesn't seem like the best opportunity to present a topic as complex and detail-oriented as this appears to be. It's also sparsely enough attended that it may not be possible to get a good feel for the attendees' views. So, question for the AC: short of a formal proposal, how do we go about getting a presentation on the meeting agenda? Finally, I'd like to thank each of you who committed privately to support a petition. We could have forced it forward and should it become necessary we still can. Let's give it another discussion and meeting cycle and see what happens first. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Mon Jan 4 11:11:02 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 04 Jan 2010 08:11:02 -0800 Subject: [arin-ppml] (can you stand one more "non-deployment of IPv6) was [Fwd: an actual IPv6 spam] Message-ID: <4B421316.3050207@ipinc.net> I got this this morning on the SA mailing list, I thought I might send it along as definitive proof that the Internet is moving to IPv6. When the spammers are starting to spam over IPv6, arguments that IPv6 deployment is mainly theoretical seem pretty silly. Ted -------- Original Message -------- Subject: an actual IPv6 spam Date: Mon, 04 Jan 2010 10:21:02 -0500 From: Greg Troxel To: users at spamassassin.apache.org (I realize that 3.2.5 does not grok v6 headers, and I believe this is fixed in 3.3, so this is more of an observation than a complaint.) Yesterday I received spam over IPv6 (and also TLS). This is the first one I've noticed, probably due to a compromised v6-capable machine, so I thought it might be of interest to others: http://www.lexort.com/spam/spam-ipv6-cn.txt From wesley at felter.org Mon Jan 4 18:13:37 2010 From: wesley at felter.org (Wes Felter) Date: Mon, 04 Jan 2010 17:13:37 -0600 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2BD575.5090800@dilkie.com> References: <200912180815.AA54264012@connetrix.com> <471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> Message-ID: Lee Dilkie wrote: > I wonder how much b/w to the home is actually needed and if there is a > natural demand "limit". It seems to me that once b/w to the home reaches > realtime HD video there's not really much more that is required... > Is it really reasonable to expect future b/w demands to the home to keep > going up and up? What drivers do you see for this? Why stop at realtime? Why not download an entire movie in one minute so you can watch it on the plane? Fortunately, this use case is very bursty and should support high oversubscription ratios. Wes Felter From charles at office.tcsn.net Mon Jan 4 19:28:30 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Mon, 04 Jan 2010 16:28:30 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2BD575.5090800@dilkie.com> References: <200912180815.AA54264012@connetrix.com> <471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> Message-ID: <4B4287AE.2010400@office.tcsn.net> Lee Dilkie wrote: > I wonder how much b/w to the home is actually needed and if there is a > natural demand "limit". It seems to me that once b/w to the home reaches > realtime HD video there's not really much more that is required (except > for separate channels for the kids, of course). If you think about it, > there's only historically been two drivers for b/w throughout the > history of communications. Ignoring the original low b/w uses, morse > code, teletype, etc, we have realtime voice and realtime video. For 80 > years, video has stabilized at about 3 Mhz b/w and it's only with the > advent of HD that we have exceeded that (is that true? I'm not sure, > considering compression and all). > > Is it really reasonable to expect future b/w demands to the home to keep > going up and up? What drivers do you see for this? > > Just curious. > > -lee > I've found that customer demands have a tendency to fall outside the bounds of reasonable expectations. Some will want more bandwidth because their neighbor/relative/friend has more than they do. Some will want more to fix a perceived problem that may or may not actually be related to their current bandwidth usage. While it may be reasonable to expect technological causes of bandwidth demand to taper, it might be imprudent to expect, and plan for, consumer bandwidth demand to follow reasonable and rational expectations. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From john.sweeting at twcable.com Tue Jan 5 09:12:50 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Tue, 5 Jan 2010 09:12:50 -0500 Subject: [arin-ppml] Not petitioning proposal 103 In-Reply-To: <3c3e3fca0912312334q6cb42e84qab0b3af14afde7b9@mail.gmail.com> Message-ID: Bill, First I would like to wish you a Happy and Prosperous New Year and second I would like to thank you on behalf of the AC for your show of cooperation and continued enthusiasm to move forward working with the AC. We owe you an answer to your question below and I will take it as an action to get you an answer as soon as possible. Last thing I want to leave with you is the fact that the AC is dedicated to recommending good, sound policy be approved and we truly appreciate all the members of the community that provide us the guidance and information required to do so. Thanks again, John On 1/1/10 2:34 AM, "William Herrin" wrote: Apparently I need to enable "mail goggles" after all. Please disregard my last message and let's try that again... On consideration, I won't petition the AC's abandonment of proposal 103. I accept the AC's conclusion that there is more that can be done in the process before pushing a formal proposal. I enthusiastically support proposal 106. Scott incorporated those parts of 103's improvements that do not depend on abandoning needs-based allocation. I think he did a good job and I think the result would significantly improve ARIN's IPv6 address management process. I'll be very disappointed if 106 is not accepted to the AC's docket for formal discussion and presentation. Proposal 103 raised another issue that I believe we should address as a community: should ARIN be the gatekeeper to Internet routing policy? In most of the time since ARIN's inception, the question has been moot: network operators depend on ARIN to act as a check on IPv4 routing table growth lest the Internet collapse. With IPv4, no credible method has been proposed for controlling route table growth without RIR policy enforcement. It's a bona fide "tragedy of the commons" problem. Proposal 103 offered a credible way to maintain control of IPv6 route table growth without requiring ARIN to act as the gatekeeper to Internet routing in North America. Perhaps not an optimal way, but at least a credible one. Now that we know there's one way, we may discover that there are more. So, now that we actually have a choice, should ARIN be set IPv6 Internet routing policy for North America? Or would we all be better off letting the ISPs reach a functional consensus that isn't tied to ARIN's operation? I'd like to see further discussion, particularly about the "how." Proposal 103 did it with ARIN fees used as a proxy to classify the network registrant's perception of the value of his system. What other methods might work? I'd also like to see all of this presented at this year's meetings. Judging from the response to proposal 103, moving ARIN out of the routing policy game has wide enough interest and support to merit presentation. Open policy hour doesn't seem like the best opportunity to present a topic as complex and detail-oriented as this appears to be. It's also sparsely enough attended that it may not be possible to get a good feel for the attendees' views. So, question for the AC: short of a formal proposal, how do we go about getting a presentation on the meeting agenda? Finally, I'd like to thank each of you who committed privately to support a petition. We could have forced it forward and should it become necessary we still can. Let's give it another discussion and meeting cycle and see what happens first. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From baptista at publicroot.org Fri Jan 8 11:36:00 2010 From: baptista at publicroot.org (Joe Baptista) Date: Fri, 8 Jan 2010 11:36:00 -0500 Subject: [arin-ppml] Christopher Mettin F/U Message-ID: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> John: First a belated thank you for the update from the AUP committee on Christopher Mettin the representative of the Gymnasium Querfurt High School. I have recently sent a formal notice to Christopher's principle Dr. Daumer demanding an apology for Christopher's defamatory comments against myself in which I requested a further apology be made by the school to the members here. FYI the letter in PDF can be seen at the following URL http://bit.ly/6q0r2g kindest regards joe baptista On Fri, Dec 4, 2009 at 10:53 PM, John Curran wrote: > Acting on the recommendation of the ARIN Mailing List AUP Committee, > Christopher Mettin has been sent formal notice to cease defamatory > posting to ARIN's mailing lists, and that even a single additional post of > such nature may result in the immediate loss of his posting privileges. > FYI, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vaughn at SwiftSystems.com Fri Jan 8 11:40:51 2010 From: Vaughn at SwiftSystems.com (VAUGHN THURMAN - SWIFT SYSTEMS INC) Date: Fri, 8 Jan 2010 11:40:51 -0500 Subject: [arin-ppml] Christopher Mettin (censored nonsense) In-Reply-To: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> References: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> Message-ID: <01d101ca9081$56d65b30$04831190$@com> With all due respect, this is a soap opera that does not belong on this list. Please cease and desist. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Baptista Sent: Friday, January 08, 2010 11:36 AM To: John Curran Cc: arin ppml Subject: Re: [arin-ppml] Christopher Mettin John: First a belated thank you for the update from the AUP committee on Christopher Mettin the representative of the Gymnasium Querfurt High School. I have recently sent a formal notice to Christopher's principle Dr. Daumer demanding an apology for Christopher's defamatory comments against myself in which I requested a further apology be made by the school to the members here. FYI the letter in PDF can be seen at the following URL http://bit.ly/6q0r2g kindest regards joe baptista On Fri, Dec 4, 2009 at 10:53 PM, John Curran wrote: Acting on the recommendation of the ARIN Mailing List AUP Committee, Christopher Mettin has been sent formal notice to cease defamatory posting to ARIN's mailing lists, and that even a single additional post of such nature may result in the immediate loss of his posting privileges. FYI, /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From baptista at publicroot.org Fri Jan 8 11:58:11 2010 From: baptista at publicroot.org (Joe Baptista) Date: Fri, 8 Jan 2010 11:58:11 -0500 Subject: [arin-ppml] Christopher Mettin (censored nonsense) In-Reply-To: <01d101ca9081$56d65b30$04831190$@com> References: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> <01d101ca9081$56d65b30$04831190$@com> Message-ID: <874c02a21001080858m45218805n3390748e5d69661a@mail.gmail.com> Vaughn the soap opera is long over. This is the follow up which is proper. A number of members here contacted me back then and said that Christopher should apologize to the members. I agree. Unfortunately Christopher has refused to do so and I think the school now has an obligation to make an apology. As you can see I mentioned this in my letter to the school principle and have posted the same here to ensure the members know an apology has been requested by me as a member here on behalf of the members of this forum. kindest regards joe baptista On Fri, Jan 8, 2010 at 11:40 AM, VAUGHN THURMAN - SWIFT SYSTEMS INC < Vaughn at swiftsystems.com> wrote: > With all due respect, this is a soap opera that does not belong on this > list. > > > > Please cease and desist. > > > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Joe Baptista > *Sent:* Friday, January 08, 2010 11:36 AM > *To:* John Curran > *Cc:* arin ppml > *Subject:* Re: [arin-ppml] Christopher Mettin > > > > John: > > First a belated thank you for the update from the AUP committee on > Christopher Mettin the representative of the Gymnasium Querfurt High School. > > I have recently sent a formal notice to Christopher's principle Dr. Daumer > demanding an apology for Christopher's defamatory comments against myself in > which I requested a further apology be made by the school to the members > here. > > FYI the letter in PDF can be seen at the following URL > > http://bit.ly/6q0r2g > > kindest regards > joe baptista > > On Fri, Dec 4, 2009 at 10:53 PM, John Curran wrote: > > Acting on the recommendation of the ARIN Mailing List AUP Committee, > Christopher Mettin has been sent formal notice to cease defamatory > posting to ARIN's mailing lists, and that even a single additional post of > such nature may result in the immediate loss of his posting privileges. > > > FYI, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > > -- > Joe Baptista > > www.publicroot.org > PublicRoot Consortium > ---------------------------------------------------------------- > The future of the Internet is Open, Transparent, Inclusive, Representative > & Accountable to the Internet community @large. > ---------------------------------------------------------------- > Office: +1 (360) 526-6077 (extension 052) > Fax: +1 (509) 479-0084 > > Personal: http://baptista.cynikal.net/ > -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at impulse.net Fri Jan 8 11:58:11 2010 From: jay at impulse.net (Jay Hennigan) Date: Fri, 08 Jan 2010 08:58:11 -0800 Subject: [arin-ppml] Christopher Mettin (censored nonsense) In-Reply-To: <01d101ca9081$56d65b30$04831190$@com> References: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> <01d101ca9081$56d65b30$04831190$@com> Message-ID: <4B476423.3010408@impulse.net> VAUGHN THURMAN - SWIFT SYSTEMS INC wrote: > With all due respect, this is a soap opera that does not belong on this > list. I *think* that "F/U" in this case was *supposed* to mean "Follow-up", not a reference to censored nonsense. I'm not 100% certain about this. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From baptista at publicroot.org Fri Jan 8 12:15:51 2010 From: baptista at publicroot.org (Joe Baptista) Date: Fri, 8 Jan 2010 12:15:51 -0500 Subject: [arin-ppml] Christopher Mettin (censored nonsense) In-Reply-To: <4B476423.3010408@impulse.net> References: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> <01d101ca9081$56d65b30$04831190$@com> <4B476423.3010408@impulse.net> Message-ID: <874c02a21001080915k49c29353n797feb4a8b3af3b8@mail.gmail.com> Jay you are 100% correct. F/U does mean Follow-up. Or at least thats what it means to me. My apologies to anyone here who misinterpreted it as anything else. I forget not all people here may be familiar with F/U as a business practice and may misinterpret it as gutter slang. Thank you jay for the clarification. kindest regards joe baptista On Fri, Jan 8, 2010 at 11:58 AM, Jay Hennigan wrote: > VAUGHN THURMAN - SWIFT SYSTEMS INC wrote: > >> With all due respect, this is a soap opera that does not belong on this >> list. >> > > I *think* that "F/U" in this case was *supposed* to mean "Follow-up", not a > reference to censored nonsense. I'm not 100% certain about this. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > _______________________________________________ > 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. > -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sat Jan 9 21:12:49 2010 From: jcurran at arin.net (John Curran) Date: Sat, 9 Jan 2010 21:12:49 -0500 Subject: [arin-ppml] Christopher Mettin In-Reply-To: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> References: <874c02a21001080836i51906049pbca69b4e22e21658@mail.gmail.com> Message-ID: <53F2BD91-E8CC-4E1D-81E8-E0C274E28825@arin.net> On Jan 8, 2010, at 8:36 AM, Joe Baptista wrote: John: First a belated thank you for the update from the AUP committee on Christopher Mettin the representative of the Gymnasium Querfurt High School. I have recently sent a formal notice to Christopher's principle Dr. Daumer demanding an apology for Christopher's defamatory comments against myself in which I requested a further apology be made by the school to the members here. FYI the letter in PDF can be seen at the following URL http://bit.ly/6q0r2g kindest regards joe baptista Joe - To the extent that you consider it your duty to keep the community informed in this matter, please consider that duty fully discharged at this point. It would be best if all would refrain from further email on this topic on the PPML list, as it is not relevant to the formation of public number resource policy. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jan 12 18:04:00 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Jan 2010 15:04:00 -0800 Subject: [arin-ppml] Proposal 99 -- Incorporating Staff and Legal comments Message-ID: <135C6BE6-D799-46D0-8AEC-701A856BA702@delong.com> Summary of changes: 1. Removed last sentence of section 4.3.2.2, per staff recommendation. 2. Added "4.3" to section 4.3.6.2 resulting in "...return all existing 4.3 assignments...", per staff recommendation. 3. Change title for section 4.3.6.2, per staff recommendation. I do not believe this significantly changes the meaning or intent of the policy, but, I agree that the proposed changes clarify the original intent of the policy. As such, I am submitting these revisions and request that the community comment on the revised proposal. It is my hope that the AC will take up this proposal for adoption discussion at the next ARIN public policy meeting. Thank you, Owen TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: /24 End User Minimum Allocation Unit 2. Proposal Originator a. name: Owen DeLong b. email: owen at delong.com c. telephone: 408-890-7992 d. organization: Hurricane Electric 3. Proposal Version: 1.2 4. Date: 12 January 2010 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If prefixes longer than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Additional Assignments for Small Multihomers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing 4.3 assignments within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. 8. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. FAQs and responses to Staff Questions Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. 9. Timetable for implementation: Immediate END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Jan 12 18:24:10 2010 From: bill at herrin.us (William Herrin) Date: Tue, 12 Jan 2010 18:24:10 -0500 Subject: [arin-ppml] Proposal 99 -- Incorporating Staff and Legal comments In-Reply-To: <135C6BE6-D799-46D0-8AEC-701A856BA702@delong.com> References: <135C6BE6-D799-46D0-8AEC-701A856BA702@delong.com> Message-ID: <3c3e3fca1001121524g5b683b4bmfe39c2293cb768bb@mail.gmail.com> On Tue, Jan 12, 2010 at 6:04 PM, Owen DeLong wrote: > 4.3.6.2 Additional Assignments for Small Multihomers > > Any end-user that possesses an assignment smaller than /22 under any part of > section 4.3 shall not be able to get an additional assignment unless they > agree to return all existing 4.3 assignments within 12 months of receiving a > new assignment. Hi Owen, Suggest a little wordsmithing here. What if I have a /16, merge with a company that has a /24 and then need an additional /20 to accommodate my growth? The above text could be construed to require me to return the /24 -and- the /16 in order to get the /20. In general, I support this proposal. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cmettin at gqbc-online.com Wed Jan 13 10:36:55 2010 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Wed, 13 Jan 2010 16:36:55 +0100 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Message-ID: Dear ARIN Community, To strengthen education of high school education, even outside the walls of such an institution, in Mai 2008 the students of the Gymnasium Querfurt High School founded the Gymnasium Querfurt Broadcasting Channel, an International organization. It's bylaws were soon written and meant to chronologically include all future amendments and extensions to the mission of the organizations, these bylaws are known as the GQ RFCs, in honor of the Requests for Change. A few months afterwards the organizations was absorbed by the GQHS and managed together with GQHS teachers. Three days ago from today, this action was reversed together with our principal and the school assembly. The GQBC administration, namely I, wanted to ensure the organization will be still administrated according to its founding principles after my own graduation and those of my fellow student network administrators. 3 official reasons were stated in the spin-off contract: 1. The fusion of GQBC with GQHS has never been authorized by a ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC growing in its first life phases; 2. GQ RFC 1 clearly stated that GQBC is an independent organization with the mission to support education. To maintain objectivity such an organization has to be run independently from a school. We only remained a phrase advising that GQBC originated from the GQHS on our website, and also GQBC will still provide services for the GQHS it provided before (e.g. web transcripts); and 3. Due to massive email, fax, and even telephone fraud attacks by an opponent of the Public-Root (name intentionally omitted but we are sure everyone knows him), which already satisfy the definition of terrorism, and the fact that GQ RFCs did never grant GQBC the right to provide contact details of the GQHS to entities other than educational institutions. GQBC amended its policies and the contact page on gqbc-online.com to state that the only way for individuals and companies outside the state of Sachsen-Anhalt to contact the school is through a spam-filtered email address. It is entirely true that the attacker failed his goal to knock down the development of a global school network (GQNET), and we can proudly say it was not the fate of the pilot project for International education to fail. The attacker will soon receive a message from our principal stating the school is no longer responsible for his falsified claims and "scam warnings" and he will have to immediately stop to write any faxes, emails, or call the school. GQNET which was planned within the last weeks is now ready to start. There will be three main departments the network consists of: an Internet Service provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET domain management (GQ NIC), and the team re-deploying the internal GQHS network to serve educational resources to the global GQNET (GQNET next-gen school network). GQNET.Connect is hereby officially introduced as the first educational Internet Service Provider with multi-homed deployment which will soon go on with the work I began, making IP addresses available for educational purposes free of charge. And of course, GQNET.Connect is primarily based in Michigan), therefore subject to be served by ARIN with IP addresses. I hope we can soon find a way to get the important IP's without long discussions caused by commercial companies trying to reserve IP addresses for their own prosper. The Web is an exponentially growing knowledge library and not the stock market. For those of you who want to benefit from a more inclusive name space the Public-Root, root of the Internet2 and our Top Level Domain sponsor, provides, go on http://inaic.com to receive further information on how to upgrade your desktop configurations and server hint files. Users of the Public-Root have instant access to most GQNET resources. Further, the Public-Root has master servers on all over the world and is therefore more reliable than the commercial legacy root, which is mainly deployed on the East and West coast of the US. Sincerely yours, Christopher Mettin Student Network Administrator GQBC -------------- next part -------------- An HTML attachment was scrubbed... URL: From baptista at publicroot.org Wed Jan 13 11:18:35 2010 From: baptista at publicroot.org (Joe Baptista) Date: Wed, 13 Jan 2010 11:18:35 -0500 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education In-Reply-To: References: Message-ID: <874c02a21001130818y2154b8cdx77003068f5a3ed02@mail.gmail.com> A very interesting development Christopher. But members reading this may be confused. So will provide here a brief summary. Three days ago I faxed the Principle at Christopher's school the "Gymnasium Querfurt High School" a letter and supporting documentation with respect to Christopher's conduct in this conference - a copy of this fax is available for members to read at the following URL: http://bit.ly/6q0r2g As a result of my letter meetings were held and the school is now doing its best to distance itself from Christopher's projects. The school has confirmed with me that they will be replying to my fax by letter. We will see then what they have to say. I do hope the school will apologize to the members here for Christopher's conduct. And in closing I want to take this opportunity to ask Christopher in public to apologize to the members for his conduct. I have asked Christopher in private correspondence to apologize to the members. To date no apology has been received and if Christopher can't provide one I hope the school does. regards joe baptista On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin < cmettin at gqbc-online.com> wrote: > Dear ARIN Community, > > > > To strengthen education of high school education, even outside the walls of > such an institution, in Mai 2008 the students of the Gymnasium Querfurt High > School founded the Gymnasium Querfurt Broadcasting Channel, an International > organization. It?s bylaws were soon written and meant to chronologically > include all future amendments and extensions to the mission of the > organizations, these bylaws are known as the GQ RFCs, in honor of the > Requests for Change. > > > > A few months afterwards the organizations was absorbed by the GQHS and > managed together with GQHS teachers. Three days ago from today, this action > was reversed together with our principal and the school assembly. The GQBC > administration, namely I, wanted to ensure the organization will be still > administrated according to its founding principles after my own graduation > and those of my fellow student network administrators. > > > > 3 official reasons were stated in the spin-off contract: > > 1. The fusion of GQBC with GQHS has never been authorized by a > ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC > growing in its first life phases; > > 2. GQ RFC 1 clearly stated that GQBC is an independent organization > with the mission to support education. To maintain objectivity such an > organization has to be run independently from a school. We only remained a > phrase advising that GQBC originated from the GQHS on our website, and also > GQBC will still provide services for the GQHS it provided before (e.g. web > transcripts); and > > 3. Due to massive email, fax, and even telephone fraud attacks by an > opponent of the Public-Root (name intentionally omitted but we are sure > everyone knows him), which already satisfy the definition of terrorism, and > the fact that GQ RFCs did never grant GQBC the right to provide contact > details of the GQHS to entities other than educational institutions. GQBC > amended its policies and the contact page on gqbc-online.com to state that > the only way for individuals and companies outside the state of > Sachsen-Anhalt to contact the school is through a spam-filtered email > address. > > > > It is entirely true that the attacker failed his goal to knock down the > development of a global school network (GQNET), and we can proudly say it > was not the fate of the pilot project for International education to fail. > The attacker will soon receive a message from our principal stating the > school is no longer responsible for his falsified claims and ?scam warnings? > and he will have to immediately stop to write any faxes, emails, or call the > school. > > > > GQNET which was planned within the last weeks is now ready to start. There > will be three main departments the network consists of: an Internet Service > provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET > domain management (GQ NIC), and the team re-deploying the internal GQHS > network to serve educational resources to the global GQNET (GQNET next-gen > school network). > > > > GQNET.Connect is hereby officially introduced as the first educational > Internet Service Provider with multi-homed deployment which will soon go on > with the work I began, making IP addresses available for educational > purposes free of charge. And of course, GQNET.Connect is primarily based in > Michigan), therefore subject to be served by ARIN with IP addresses. > > > > I hope we can soon find a way to get the important IP?s without long > discussions caused by commercial companies trying to reserve IP addresses > for their own prosper. The Web is an exponentially growing knowledge library > and not the stock market. > > > > For those of you who want to benefit from a more inclusive name space the > Public-Root, root of the Internet2 and our Top Level Domain sponsor, > provides, go on http://inaic.com to receive further information on how to > upgrade your desktop configurations and server hint files. Users of the > Public-Root have instant access to most GQNET resources. Further, the > Public-Root has master servers on all over the world and is therefore more > reliable than the commercial legacy root, which is mainly deployed on the > East and West coast of the US. > > > > Sincerely yours, > > Christopher Mettin > > Student Network Administrator > > GQBC > > _______________________________________________ > 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 cmettin at gqbc-online.com Wed Jan 13 11:57:21 2010 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Wed, 13 Jan 2010 17:57:21 +0100 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Message-ID: Oh, someone admitting his guilt. I was counting on that. Yep, that's the guy who was wasting our limited school paper. 4 week days in a row we received faxes (the one he linked was only the second one) containing falsified claims and crazy threats. This behavior violates the United States Code (don't ask me for the exact section and clause). If they don't stop contacting our school immediately, we will take legal actions. If anyone googles up, they will find a dozen of emails and faxes he sent to government offices and non-commercial organizations. It is also a falsification to identify oneself as a member of an organization that fired one and now tries to convince other people to not work with this company (as Mr. Baptista does). Is advised to ignore Mr. Baptista as everyone of the other affected people did. If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then. No further comments requested. From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Wednesday, January 13, 2010 5:19 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education A very interesting development Christopher. But members reading this may be confused. So will provide here a brief summary. Three days ago I faxed the Principle at Christopher's school the "Gymnasium Querfurt High School" a letter and supporting documentation with respect to Christopher's conduct in this conference - a copy of this fax is available for members to read at the following URL: http://bit.ly/6q0r2g As a result of my letter meetings were held and the school is now doing its best to distance itself from Christopher's projects. The school has confirmed with me that they will be replying to my fax by letter. We will see then what they have to say. I do hope the school will apologize to the members here for Christopher's conduct. And in closing I want to take this opportunity to ask Christopher in public to apologize to the members for his conduct. I have asked Christopher in private correspondence to apologize to the members. To date no apology has been received and if Christopher can't provide one I hope the school does. regards joe baptista On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin wrote: Dear ARIN Community, To strengthen education of high school education, even outside the walls of such an institution, in Mai 2008 the students of the Gymnasium Querfurt High School founded the Gymnasium Querfurt Broadcasting Channel, an International organization. It's bylaws were soon written and meant to chronologically include all future amendments and extensions to the mission of the organizations, these bylaws are known as the GQ RFCs, in honor of the Requests for Change. A few months afterwards the organizations was absorbed by the GQHS and managed together with GQHS teachers. Three days ago from today, this action was reversed together with our principal and the school assembly. The GQBC administration, namely I, wanted to ensure the organization will be still administrated according to its founding principles after my own graduation and those of my fellow student network administrators. 3 official reasons were stated in the spin-off contract: 1. The fusion of GQBC with GQHS has never been authorized by a ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC growing in its first life phases; 2. GQ RFC 1 clearly stated that GQBC is an independent organization with the mission to support education. To maintain objectivity such an organization has to be run independently from a school. We only remained a phrase advising that GQBC originated from the GQHS on our website, and also GQBC will still provide services for the GQHS it provided before (e.g. web transcripts); and 3. Due to massive email, fax, and even telephone fraud attacks by an opponent of the Public-Root (name intentionally omitted but we are sure everyone knows him), which already satisfy the definition of terrorism, and the fact that GQ RFCs did never grant GQBC the right to provide contact details of the GQHS to entities other than educational institutions. GQBC amended its policies and the contact page on gqbc-online.com to state that the only way for individuals and companies outside the state of Sachsen-Anhalt to contact the school is through a spam-filtered email address. It is entirely true that the attacker failed his goal to knock down the development of a global school network (GQNET), and we can proudly say it was not the fate of the pilot project for International education to fail. The attacker will soon receive a message from our principal stating the school is no longer responsible for his falsified claims and "scam warnings" and he will have to immediately stop to write any faxes, emails, or call the school. GQNET which was planned within the last weeks is now ready to start. There will be three main departments the network consists of: an Internet Service provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET domain management (GQ NIC), and the team re-deploying the internal GQHS network to serve educational resources to the global GQNET (GQNET next-gen school network). GQNET.Connect is hereby officially introduced as the first educational Internet Service Provider with multi-homed deployment which will soon go on with the work I began, making IP addresses available for educational purposes free of charge. And of course, GQNET.Connect is primarily based in Michigan), therefore subject to be served by ARIN with IP addresses. I hope we can soon find a way to get the important IP's without long discussions caused by commercial companies trying to reserve IP addresses for their own prosper. The Web is an exponentially growing knowledge library and not the stock market. For those of you who want to benefit from a more inclusive name space the Public-Root, root of the Internet2 and our Top Level Domain sponsor, provides, go on http://inaic.com to receive further information on how to upgrade your desktop configurations and server hint files. Users of the Public-Root have instant access to most GQNET resources. Further, the Public-Root has master servers on all over the world and is therefore more reliable than the commercial legacy root, which is mainly deployed on the East and West coast of the US. Sincerely yours, Christopher Mettin Student Network Administrator GQBC _______________________________________________ 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 Lee at Dilkie.com Wed Jan 13 12:31:30 2010 From: Lee at Dilkie.com (Lee Dilkie) Date: Wed, 13 Jan 2010 12:31:30 -0500 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education In-Reply-To: References: Message-ID: <4B4E0372.6090004@Dilkie.com> Sweet Jesus in the garden of Gethsemane, keep us and save us from this crap. Can both of you just shut the frak up. You're acting like a bunch of children. -lee On 1/13/2010 11:57 AM, Christopher Mettin wrote: > > Oh, someone admitting his guilt. I was counting on that. Yep, that's > the guy who was wasting our limited school paper. > > 4 week days in a row we received faxes (the one he linked was only the > second one) containing falsified claims and crazy threats. This > behavior violates the United States Code (don't ask me for the exact > section and clause). > > > > If they don't stop contacting our school immediately, we will take > legal actions. > > > > If anyone googles up, they will find a dozen of emails and faxes he > sent to government offices and non-commercial organizations. It is > also a falsification to identify oneself as a member of an > organization that fired one and now tries to convince other people to > not work with this company (as Mr. Baptista does). Is advised to > ignore Mr. Baptista as everyone of the other affected people did. > > > > If Mr. Baptista thinks he knows better about our internal school > business, he can go tell his grandma, uh, no, I forgot he lives with > his Mama, maybe she will still pay the next Internet bill then. > > > > No further comments requested. > > > > *From:* publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] > *On Behalf Of *Joe Baptista > *Sent:* Wednesday, January 13, 2010 5:19 PM > *To:* Christopher Mettin > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from > the Gymnasium Querfurt High School to enhance education > > > > A very interesting development Christopher. But members reading this > may be confused. So will provide here a brief summary. > > Three days ago I faxed the Principle at Christopher's school the > "Gymnasium Querfurt High School" a letter and supporting documentation > with respect to Christopher's conduct in this conference - a copy of > this fax is available for members to read at the following URL: > > http://bit.ly/6q0r2g > > As a result of my letter meetings were held and the school is now > doing its best to distance itself from Christopher's projects. > > The school has confirmed with me that they will be replying to my fax > by letter. We will see then what they have to say. > > I do hope the school will apologize to the members here for > Christopher's conduct. > > And in closing I want to take this opportunity to ask Christopher in > public to apologize to the members for his conduct. I have asked > Christopher in private correspondence to apologize to the members. To > date no apology has been received and if Christopher can't provide one > I hope the school does. > > > regards > joe baptista > > On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin > > wrote: > > Dear ARIN Community, > > > > To strengthen education of high school education, even outside the > walls of such an institution, in Mai 2008 the students of the > Gymnasium Querfurt High School founded the Gymnasium Querfurt > Broadcasting Channel, an International organization. It's bylaws were > soon written and meant to chronologically include all future > amendments and extensions to the mission of the organizations, these > bylaws are known as the GQ RFCs, in honor of the Requests for Change. > > > > A few months afterwards the organizations was absorbed by the GQHS and > managed together with GQHS teachers. Three days ago from today, this > action was reversed together with our principal and the school > assembly. The GQBC administration, namely I, wanted to ensure the > organization will be still administrated according to its founding > principles after my own graduation and those of my fellow student > network administrators. > > > > 3 official reasons were stated in the spin-off contract: > > 1. The fusion of GQBC with GQHS has never been authorized by a > ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC > growing in its first life phases; > > 2. GQ RFC 1 clearly stated that GQBC is an independent > organization with the mission to support education. To maintain > objectivity such an organization has to be run independently from a > school. We only remained a phrase advising that GQBC originated from > the GQHS on our website, and also GQBC will still provide services for > the GQHS it provided before (e.g. web transcripts); and > > 3. Due to massive email, fax, and even telephone fraud attacks > by an opponent of the Public-Root (name intentionally omitted but we > are sure everyone knows him), which already satisfy the definition of > terrorism, and the fact that GQ RFCs did never grant GQBC the right to > provide contact details of the GQHS to entities other than educational > institutions. GQBC amended its policies and the contact page on > gqbc-online.com to state that the only way > for individuals and companies outside the state of Sachsen-Anhalt to > contact the school is through a spam-filtered email address. > > > > It is entirely true that the attacker failed his goal to knock down > the development of a global school network (GQNET), and we can proudly > say it was not the fate of the pilot project for International > education to fail. The attacker will soon receive a message from our > principal stating the school is no longer responsible for his > falsified claims and "scam warnings" and he will have to immediately > stop to write any faxes, emails, or call the school. > > > > GQNET which was planned within the last weeks is now ready to start. > There will be three main departments the network consists of: an > Internet Service provider (GQNET.Connect) connecting all users to the > GQNET , the .GQNET domain management (GQ NIC), and the team > re-deploying the internal GQHS network to serve educational resources > to the global GQNET (GQNET next-gen school network). > > > > GQNET.Connect is hereby officially introduced as the first educational > Internet Service Provider with multi-homed deployment which will soon > go on with the work I began, making IP addresses available for > educational purposes free of charge. And of course, GQNET.Connect is > primarily based in Michigan), therefore subject to be served by ARIN > with IP addresses. > > > > I hope we can soon find a way to get the important IP's without long > discussions caused by commercial companies trying to reserve IP > addresses for their own prosper. The Web is an exponentially growing > knowledge library and not the stock market. > > > > For those of you who want to benefit from a more inclusive name space > the Public-Root, root of the Internet2 and our Top Level Domain > sponsor, provides, go on http://inaic.com to receive further > information on how to upgrade your desktop configurations and server > hint files. Users of the Public-Root have instant access to most GQNET > resources. Further, the Public-Root has master servers on all over the > world and is therefore more reliable than the commercial legacy root, > which is mainly deployed on the East and West coast of the US. > > > > Sincerely yours, > > Christopher Mettin > > Student Network Administrator > > GQBC > > > _______________________________________________ > 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 cboyd at gizmopartners.com Wed Jan 13 12:34:20 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 13 Jan 2010 11:34:20 -0600 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education In-Reply-To: References: Message-ID: <68FE42C1-1134-446B-B293-EAE069FCE97C@gizmopartners.com> To quote Douglas Adams, as the whale crashed to the ground: "Oh no, not again." From cmalayter at switchanddata.com Wed Jan 13 12:57:26 2010 From: cmalayter at switchanddata.com (Chris Malayter) Date: Wed, 13 Jan 2010 12:57:26 -0500 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education In-Reply-To: <4B4E0372.6090004@Dilkie.com> References: <4B4E0372.6090004@Dilkie.com> Message-ID: Do not feed the troll.... On Jan 13, 2010, at 11:31 AM, Lee Dilkie wrote: > Sweet Jesus in the garden of Gethsemane, keep us and save us from this crap. > > Can both of you just shut the frak up. You're acting like a bunch of children. > > -lee > > On 1/13/2010 11:57 AM, Christopher Mettin wrote: >> Oh, someone admitting his guilt. I was counting on that. Yep, that?s the guy who was wasting our limited school paper. >> >> 4 week days in a row we received faxes (the one he linked was only the second one) containing falsified claims and crazy threats. This behavior violates the United States Code (don?t ask me for the exact section and clause). >> >> >> >> If they don?t stop contacting our school immediately, we will take legal actions. >> >> >> >> If anyone googles up, they will find a dozen of emails and faxes he sent to government offices and non-commercial organizations. It is also a falsification to identify oneself as a member of an organization that fired one and now tries to convince other people to not work with this company (as Mr. Baptista does). Is advised to ignore Mr. Baptista as everyone of the other affected people did. >> >> >> >> If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then. >> >> >> >> No further comments requested. >> >> >> >> From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista >> Sent: Wednesday, January 13, 2010 5:19 PM >> To: Christopher Mettin >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education >> >> >> >> A very interesting development Christopher. But members reading this may be confused. So will provide here a brief summary. >> >> Three days ago I faxed the Principle at Christopher's school the "Gymnasium Querfurt High School" a letter and supporting documentation with respect to Christopher's conduct in this conference - a copy of this fax is available for members to read at the following URL: >> >> http://bit.ly/6q0r2g >> >> As a result of my letter meetings were held and the school is now doing its best to distance itself from Christopher's projects. >> >> The school has confirmed with me that they will be replying to my fax by letter. We will see then what they have to say. >> >> I do hope the school will apologize to the members here for Christopher's conduct. >> >> And in closing I want to take this opportunity to ask Christopher in public to apologize to the members for his conduct. I have asked Christopher in private correspondence to apologize to the members. To date no apology has been received and if Christopher can't provide one I hope the school does. >> >> >> regards >> joe baptista >> >> On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin wrote: >> >> Dear ARIN Community, >> >> >> >> To strengthen education of high school education, even outside the walls of such an institution, in Mai 2008 the students of the Gymnasium Querfurt High School founded the Gymnasium Querfurt Broadcasting Channel, an International organization. It?s bylaws were soon written and meant to chronologically include all future amendments and extensions to the mission of the organizations, these bylaws are known as the GQ RFCs, in honor of the Requests for Change. >> >> >> >> A few months afterwards the organizations was absorbed by the GQHS and managed together with GQHS teachers. Three days ago from today, this action was reversed together with our principal and the school assembly. The GQBC administration, namely I, wanted to ensure the organization will be still administrated according to its founding principles after my own graduation and those of my fellow student network administrators. >> >> >> >> 3 official reasons were stated in the spin-off contract: >> >> 1. The fusion of GQBC with GQHS has never been authorized by a ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC growing in its first life phases; >> >> 2. GQ RFC 1 clearly stated that GQBC is an independent organization with the mission to support education. To maintain objectivity such an organization has to be run independently from a school. We only remained a phrase advising that GQBC originated from the GQHS on our website, and also GQBC will still provide services for the GQHS it provided before (e.g. web transcripts); and >> >> 3. Due to massive email, fax, and even telephone fraud attacks by an opponent of the Public-Root (name intentionally omitted but we are sure everyone knows him), which already satisfy the definition of terrorism, and the fact that GQ RFCs did never grant GQBC the right to provide contact details of the GQHS to entities other than educational institutions. GQBC amended its policies and the contact page on gqbc-online.com to state that the only way for individuals and companies outside the state of Sachsen-Anhalt to contact the school is through a spam-filtered email address. >> >> >> >> It is entirely true that the attacker failed his goal to knock down the development of a global school network (GQNET), and we can proudly say it was not the fate of the pilot project for International education to fail. The attacker will soon receive a message from our principal stating the school is no longer responsible for his falsified claims and ?scam warnings? and he will have to immediately stop to write any faxes, emails, or call the school. >> >> >> >> GQNET which was planned within the last weeks is now ready to start. There will be three main departments the network consists of: an Internet Service provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET domain management (GQ NIC), and the team re-deploying the internal GQHS network to serve educational resources to the global GQNET (GQNET next-gen school network). >> >> >> >> GQNET.Connect is hereby officially introduced as the first educational Internet Service Provider with multi-homed deployment which will soon go on with the work I began, making IP addresses available for educational purposes free of charge. And of course, GQNET.Connect is primarily based in Michigan), therefore subject to be served by ARIN with IP addresses. >> >> >> >> I hope we can soon find a way to get the important IP?s without long discussions caused by commercial companies trying to reserve IP addresses for their own prosper. The Web is an exponentially growing knowledge library and not the stock market. >> >> >> >> For those of you who want to benefit from a more inclusive name space the Public-Root, root of the Internet2 and our Top Level Domain sponsor, provides, go on http://inaic.com to receive further information on how to upgrade your desktop configurations and server hint files. Users of the Public-Root have instant access to most GQNET resources. Further, the Public-Root has master servers on all over the world and is therefore more reliable than the commercial legacy root, which is mainly deployed on the East and West coast of the US. >> >> >> >> Sincerely yours, >> >> Christopher Mettin >> >> Student Network Administrator >> >> GQBC >> >> >> _______________________________________________ >> 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 farmer at umn.edu Wed Jan 13 14:17:37 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 13 Jan 2010 13:17:37 -0600 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education In-Reply-To: References: Message-ID: <4B4E1C51.9030309@umn.edu> Christopher, I wish you well in your efforts. However, from what I saw on your website your claims of educational purposes seem to stretch creditability. This is simply my opinion and you are free to ignore it as you see fit. Furthermore you, like anyone else, are welcome to use the Internet for what ever you see fit, educational or otherwise, within the applicable laws of course. But, when you claim an exception from policies and fees to further education purposes you should be able to clearly and reasonably demonstrate the educational value you are providing to society. And, I just don't see that in this case, again this is simply my opinion. Christopher Mettin wrote: > GQNET.Connect is hereby officially introduced as the first educational > Internet Service Provider with multi-homed deployment which will soon go > on with the work I began, making IP addresses available for educational > purposes free of charge. And of course, GQNET.Connect is primarily based > in Michigan), therefore subject to be served by ARIN with IP addresses. Beyond that, I must additionally take issue with your claim, "as the first educational Internet Service Provider". Your effort is by no means the first education Internet Service Provider. I will point you to Merit as a easy counter point example. I'm not sure who the first education ISP really is, but as Merit has been around since 1966 and has a far better claim to that title. See: http://www.merit.edu/about/ You might want to learn more about Internet history. At one point in time, Merit was the operator of the NSFNet, which was the Internet for all intensive purposes in the early 1990s. See: http://en.wikipedia.org/wiki/National_Science_Foundation_Network http://www.livinginternet.com/i/ii_nsfnet.htm > For those of you who want to benefit from a more inclusive name space > the Public-Root, root of the Internet2 and our Top Level Domain sponsor, > provides, go on http://inaic.com to receive further information on how > to upgrade your desktop configurations and server hint files. Users of > the Public-Root have instant access to most GQNET resources. Further, > the Public-Root has master servers on all over the world and is > therefore more reliable than the commercial legacy root, which is mainly > deployed on the East and West coast of the US. Additionally, your project is not the root of Internet2, I personally have participated a great deal in the work of the Internet2 project for over 10 years. See: http://www.internet2.edu/about/ And by the way Internet2 is a trademark. See: http://www.internet2.edu/termsofuse.html In conclusion, while I wish you well in your efforts, I and many others would like to be able to focus on the policy business of ARIN. Therefore I would like to request you at least try to keep your postings relevant to that subject. If you can do this, your continued participation is welcome. Thank you. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From info at arin.net Wed Jan 13 15:06:26 2010 From: info at arin.net (Member Services) Date: Wed, 13 Jan 2010 15:06:26 -0500 Subject: [arin-ppml] =?windows-1252?q?NRPM_2010=2E1_=96_New_Policies_Imple?= =?windows-1252?q?mented?= Message-ID: <4B4E27C2.6040805@arin.net> On 18 December 2009 the ARIN Board of Trustees, based on the recommendation of the Advisory Council and noting that the Policy Development Process had been followed, adopted the following number resource policies: 2008-3: Community Networks IPv6 Assignment 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries 2009-5: IPv6 Multiple Discrete Networks 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries 2009-7: Open Access To IPv6 2009-8: Equitable IPv4 Run-Out A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2010.1 contains the implementation of 2008-3, 2009-5, 2009-7 and 2009-8. The two global proposals, 2009-3 and 2009-6, await the conclusion of the Global Policy Development Process. In addition to the policy actions above the NRPM was modfied as follows: Section 5.1 (an ASN subsection) was retired according to its built-in expiration, "Section 5.1 will be removed from the first version of this manual published after 1 January 2010." Several editorial updates were made to Section 6, the IPv6 section. The IPv6 definitions were moved to Section 2 (Definitions). And the References and Background sections were retired. NRPM version 2010.1 is effective 13 January 2010 and supersedes the previous version. See the Change Log for information regarding revisions to the policy manual. The NRPM is available at: https://www.arin.net/policy/nrpm.html The Change Log is available at: https://www.arin.net/policy/nrpm_changelog.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The PDP is available at: https://www.arin.net/policy/pdp.html The Global Policy Development Process is available at: http://aso.icann.org/documents/memorandum-of-understanding/ Regards, Member Services American Registry for Internet Numbers (ARIN) From marty at akamai.com Wed Jan 13 15:23:10 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 13 Jan 2010 15:23:10 -0500 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <4B4E27C2.6040805@arin.net> Message-ID: On 1/13/10 3:06 PM, "Member Services" wrote: > On 18 December 2009 the ARIN Board of Trustees, based on the > recommendation of the Advisory Council and noting that the Policy > Development Process had been followed, adopted the following number > resource policies: > [ snip ] > > 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional > Internet Registries [ clip ] > 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) > Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries > [ clip ] > > The two global proposals, 2009-3 and 2009-6, await the conclusion of the > Global Policy Development Process. This is ambiguous. Could you please clarify? Since both of these globally submitted policies have been accepted by the AC, ratified by the BoT and have completed the ARIN PDP cycle they _are_ both ARIN region policies regardless of the problem with at least 2009-6 being significantly contextually different than other regions versions. That problem is not relevant so I would think that these policies are awaiting nothing that is relevant to them per se. Correct? Best, Martin -- Martin Hannigan http://www.akamai.com Akamai Technologies, Inc. marty at akamai.com Cambridge, MA USA cell: +16178216079 ofc: +16174442535 From tedm at ipinc.net Wed Jan 13 15:44:57 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 13 Jan 2010 12:44:57 -0800 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: References: Message-ID: <4B4E30C9.5010601@ipinc.net> marty at akamai.com wrote: > > > On 1/13/10 3:06 PM, "Member Services" wrote: > >> On 18 December 2009 the ARIN Board of Trustees, based on the >> recommendation of the Advisory Council and noting that the Policy >> Development Process had been followed, adopted the following number >> resource policies: >> > > [ snip ] > >> 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional >> Internet Registries > > [ clip ] > >> 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) >> Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries >> > > [ clip ] > >> The two global proposals, 2009-3 and 2009-6, await the conclusion of the >> Global Policy Development Process. > > > This is ambiguous. Could you please clarify? > > Since both of these globally submitted policies have been accepted by the > AC, ratified by the BoT and have completed the ARIN PDP cycle they _are_ > both ARIN region policies regardless of the problem with at least 2009-6 > being significantly contextually different than other regions versions. That > problem is not relevant so I would think that these policies are awaiting > nothing that is relevant to them per se. > > Correct? > > > Best, > > Martin > > > How exactly is IANA held to ARIN's policies? ARIN could decide that IANA give all it's remaining IPv4 to ARIN, is IANA obligated to pay attention to that? Seems to me your not going to get IANA to do jack until any policy that affects it completes the GDP. Ted From dylan.ebner at crlmed.com Wed Jan 13 16:12:24 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 13 Jan 2010 21:12:24 +0000 Subject: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education In-Reply-To: References: Message-ID: <017265BF3B9640499754DD48777C3D206717D5F3BE@MBX9.EXCHPROD.USA.NET> I think Mt. Mettin's statement, "If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then.", qualifies as violating the ARIN prohibited activities section 1, "Statements that include foul language, personal character attacks, or show disrespect for other participants, including ARIN." Can we please remove Mr. Mettin and get on with more important business? This is getting old. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Wednesday, January 13, 2010 10:57 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Oh, someone admitting his guilt. I was counting on that. Yep, that's the guy who was wasting our limited school paper. 4 week days in a row we received faxes (the one he linked was only the second one) containing falsified claims and crazy threats. This behavior violates the United States Code (don't ask me for the exact section and clause). If they don't stop contacting our school immediately, we will take legal actions. If anyone googles up, they will find a dozen of emails and faxes he sent to government offices and non-commercial organizations. It is also a falsification to identify oneself as a member of an organization that fired one and now tries to convince other people to not work with this company (as Mr. Baptista does). Is advised to ignore Mr. Baptista as everyone of the other affected people did. If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then. No further comments requested. From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Wednesday, January 13, 2010 5:19 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education A very interesting development Christopher. But members reading this may be confused. So will provide here a brief summary. Three days ago I faxed the Principle at Christopher's school the "Gymnasium Querfurt High School" a letter and supporting documentation with respect to Christopher's conduct in this conference - a copy of this fax is available for members to read at the following URL: http://bit.ly/6q0r2g As a result of my letter meetings were held and the school is now doing its best to distance itself from Christopher's projects. The school has confirmed with me that they will be replying to my fax by letter. We will see then what they have to say. I do hope the school will apologize to the members here for Christopher's conduct. And in closing I want to take this opportunity to ask Christopher in public to apologize to the members for his conduct. I have asked Christopher in private correspondence to apologize to the members. To date no apology has been received and if Christopher can't provide one I hope the school does. regards joe baptista On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin > wrote: Dear ARIN Community, To strengthen education of high school education, even outside the walls of such an institution, in Mai 2008 the students of the Gymnasium Querfurt High School founded the Gymnasium Querfurt Broadcasting Channel, an International organization. It's bylaws were soon written and meant to chronologically include all future amendments and extensions to the mission of the organizations, these bylaws are known as the GQ RFCs, in honor of the Requests for Change. A few months afterwards the organizations was absorbed by the GQHS and managed together with GQHS teachers. Three days ago from today, this action was reversed together with our principal and the school assembly. The GQBC administration, namely I, wanted to ensure the organization will be still administrated according to its founding principles after my own graduation and those of my fellow student network administrators. 3 official reasons were stated in the spin-off contract: 1. The fusion of GQBC with GQHS has never been authorized by a ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC growing in its first life phases; 2. GQ RFC 1 clearly stated that GQBC is an independent organization with the mission to support education. To maintain objectivity such an organization has to be run independently from a school. We only remained a phrase advising that GQBC originated from the GQHS on our website, and also GQBC will still provide services for the GQHS it provided before (e.g. web transcripts); and 3. Due to massive email, fax, and even telephone fraud attacks by an opponent of the Public-Root (name intentionally omitted but we are sure everyone knows him), which already satisfy the definition of terrorism, and the fact that GQ RFCs did never grant GQBC the right to provide contact details of the GQHS to entities other than educational institutions. GQBC amended its policies and the contact page on gqbc-online.com to state that the only way for individuals and companies outside the state of Sachsen-Anhalt to contact the school is through a spam-filtered email address. It is entirely true that the attacker failed his goal to knock down the development of a global school network (GQNET), and we can proudly say it was not the fate of the pilot project for International education to fail. The attacker will soon receive a message from our principal stating the school is no longer responsible for his falsified claims and "scam warnings" and he will have to immediately stop to write any faxes, emails, or call the school. GQNET which was planned within the last weeks is now ready to start. There will be three main departments the network consists of: an Internet Service provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET domain management (GQ NIC), and the team re-deploying the internal GQHS network to serve educational resources to the global GQNET (GQNET next-gen school network). GQNET.Connect is hereby officially introduced as the first educational Internet Service Provider with multi-homed deployment which will soon go on with the work I began, making IP addresses available for educational purposes free of charge. And of course, GQNET.Connect is primarily based in Michigan), therefore subject to be served by ARIN with IP addresses. I hope we can soon find a way to get the important IP's without long discussions caused by commercial companies trying to reserve IP addresses for their own prosper. The Web is an exponentially growing knowledge library and not the stock market. For those of you who want to benefit from a more inclusive name space the Public-Root, root of the Internet2 and our Top Level Domain sponsor, provides, go on http://inaic.com to receive further information on how to upgrade your desktop configurations and server hint files. Users of the Public-Root have instant access to most GQNET resources. Further, the Public-Root has master servers on all over the world and is therefore more reliable than the commercial legacy root, which is mainly deployed on the East and West coast of the US. Sincerely yours, Christopher Mettin Student Network Administrator GQBC _______________________________________________ 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 marty at akamai.com Wed Jan 13 16:44:54 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 13 Jan 2010 16:44:54 -0500 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <4B4E30C9.5010601@ipinc.net> Message-ID: On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: > marty at akamai.com wrote: >> > >> > >> > On 1/13/10 3:06 PM, "Member Services" wrote: >> > >>> >> On 18 December 2009 the ARIN Board of Trustees, based on the >>> >> recommendation of the Advisory Council and noting that the Policy >>> >> Development Process had been followed, adopted the following number >>> >> resource policies: >>> >> >> > >> > [ snip ] >> > >>> >> 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional >>> >> Internet Registries >> > >> > [ clip ] >> > >>> >> 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) >>> >> Policy for Allocation of ASN Blocks (ASNs) to Regional Internet >>> Registries >>> >> >> > >> > [ clip ] >> > >>> >> The two global proposals, 2009-3 and 2009-6, await the conclusion of the >>> >> Global Policy Development Process. >> > >> > >> > This is ambiguous. Could you please clarify? >> > >> > Since both of these globally submitted policies have been accepted by the >> > AC, ratified by the BoT and have completed the ARIN PDP cycle they _are_ >> > both ARIN region policies regardless of the problem with at least 2009-6 >> > being significantly contextually different than other regions versions. >> That >> > problem is not relevant so I would think that these policies are awaiting >> > nothing that is relevant to them per se. >> > >> > Correct? >> > >> > >> > Best, >> > >> > Martin >> > >> > >> > > > How exactly is IANA held to ARIN's policies? ARIN could decide that > IANA give all it's remaining IPv4 to ARIN, is IANA obligated to pay > attention to that? Seems to me your not going to get IANA to do > jack until any policy that affects it completes the GDP. > > Ted > Ted, Good question. Without a global policy, they aren?t. If you mean to ask how that relationship is actually governed, you can see the documents that codify the relationship and the global PDP by browsing here: http://www.nro.net/ Best, -M< -- Martin Hannigan http://www.akamai.com Akamai Technologies, Inc. marty at akamai.com Cambridge, MA USA cell: +16178216079 ofc: +16174442535 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Wed Jan 13 18:04:40 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 13 Jan 2010 15:04:40 -0800 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: References: Message-ID: <4B4E5188.7020701@ipinc.net> marty at akamai.com wrote: > On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: > >> marty at akamai.com wrote: >>>> >>>> On 1/13/10 3:06 PM, "Member Services" wrote: >>>> >>>>>> On 18 December 2009 the ARIN Board of Trustees, based on the >>>>>> recommendation of the Advisory Council and noting that the Policy >>>>>> Development Process had been followed, adopted the following number >>>>>> resource policies: >>>>>> >>>> [ snip ] >>>> >>>>>> 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional >>>>>> Internet Registries >>>> [ clip ] >>>> >>>>>> 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) >>>>>> Policy for Allocation of ASN Blocks (ASNs) to Regional Internet >>>> Registries >>>> [ clip ] >>>> >>>>>> The two global proposals, 2009-3 and 2009-6, await the conclusion of the >>>>>> Global Policy Development Process. >>>> >>>> This is ambiguous. Could you please clarify? >>>> >>>> Since both of these globally submitted policies have been accepted by the >>>> AC, ratified by the BoT and have completed the ARIN PDP cycle they _are_ >>>> both ARIN region policies regardless of the problem with at least 2009-6 >>>> being significantly contextually different than other regions versions. >>> That >>>> problem is not relevant so I would think that these policies are awaiting >>>> nothing that is relevant to them per se. >>>> >>>> Correct? >>>> >>>> >>>> Best, >>>> >>>> Martin >>>> >>>> >>>> >> How exactly is IANA held to ARIN's policies? ARIN could decide that >> IANA give all it's remaining IPv4 to ARIN, is IANA obligated to pay >> attention to that? Seems to me your not going to get IANA to do >> jack until any policy that affects it completes the GDP. >> >> Ted >> > Ted, > > Good question. Without a global policy, they aren?t. If you mean to ask how > that relationship is actually governed, you can see the documents that > codify the relationship and the global PDP by browsing here: > http://www.nro.net/ > Well, my question was more rhetorical - meaning that logically, since these policies depend on IANA doing something, they really cannot be policies until IANA agrees with them and follows them. I mean, we can stick them in the ARIN policy manual and all that but they won't be followed until completion of GDP - so in essence, your statement that " they _are_ both ARIN region policies regardless " has no meaning. It's kind of like when the US Congress passes a law then does not pass the finance bill that provides money to enforce the law - thus, even though it's on the books, it effectively does not exist. What I think is a much more interesting and relevant query is what happens if either of these policies flunk out of the GDP? Does ARIN's board then reverse their adoption and scrap them? Ted From baptista at publicroot.org Wed Jan 13 18:51:28 2010 From: baptista at publicroot.org (Joe Baptista) Date: Wed, 13 Jan 2010 18:51:28 -0500 Subject: [arin-ppml] Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Message-ID: <874c02a21001131551x5ff9b4d8j24ba74fb32b7155b@mail.gmail.com> I will not oppose the removal of Mr. Mettin this time. I don't care how old you are. I'm not a big fan of baseball so I don't believe in the three strikes rule. I'm into the one strike rule. But I appeal to the AUP Committee to please not be hasty in making a decision. I have been promised a reply at least from the school in which they will address the members. I also remind the committee and the members here that it is I who am being liable, slandered and defamed here. I therefore reserve the right to submit for the consideration of the AUP committee a representation concerning this matter. Let us not forget who you are. ARIN is an internationally respected organization. You are about to cause damage to the reputation of an 18 year old boy. All these matters are forever archived. And I don't think Christopher is completely at fault here. I think a good portion of the fault lies with his school the Gymnasium Querfurt. This boy is a victim. Both I and Christopher got involved in the INAIC Public-Root scandal. I'm an insider and even I didn't know about the fraud until I investigated in the Netherlands. It's not the boys fault that he went a little nutty trying to defend them. Again the fault is with the school. Where was the supervision? Also I point out to the AUP Committee the school is responsible for his activities and statements here. I want to see how the Gymnasium Querfurt wiggles out of that. But also they only found out about this when I faxed them some three days ago. They had no idea what was going on. I tried emailing them but Christopher has been filtering the schools email. You may remember he said so in his Spin-Off notice to ARIN-PPML. Thats another issue. He admitted he hijacked the schools email system - does the school even know? This may even be a criminal issue in Germany. But the bottom line here is that the school must share responsibility for Christopher's actions. I therefore would like some time to prepare a statement to submit to the committee. Thanks joe baptista the injured party On Wed, Jan 13, 2010 at 4:12 PM, Dylan Ebner wrote: > I think Mt. Mettin?s statement, ?If Mr. Baptista thinks he knows better > about our internal school business, he can go tell his grandma, uh, no, I > forgot he lives with his Mama, maybe she will still pay the next Internet > bill then.?, qualifies as violating the ARIN prohibited activities section > 1, ?Statements that include foul language, personal character attacks, or > show disrespect for other participants, including ARIN.? > > > > Can we please remove Mr. Mettin and get on with more important business? > This is getting old. > > > > Thanks > > > > > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > ------------------------------ > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Christopher Mettin > *Sent:* Wednesday, January 13, 2010 10:57 AM > *To:* arin-ppml at arin.net > > *Subject:* Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the > Gymnasium Querfurt High School to enhance education > > > > Oh, someone admitting his guilt. I was counting on that. Yep, that?s the > guy who was wasting our limited school paper. > > 4 week days in a row we received faxes (the one he linked was only the > second one) containing falsified claims and crazy threats. This behavior > violates the United States Code (don?t ask me for the exact section and > clause). > > > > If they don?t stop contacting our school immediately, we will take legal > actions. > > > > If anyone googles up, they will find a dozen of emails and faxes he sent to > government offices and non-commercial organizations. It is also a > falsification to identify oneself as a member of an organization that fired > one and now tries to convince other people to not work with this company (as > Mr. Baptista does). Is advised to ignore Mr. Baptista as everyone of the > other affected people did. > > > > If Mr. Baptista thinks he knows better about our internal school business, > he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe > she will still pay the next Internet bill then. > > > > No further comments requested. > > > > *From:* publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] *On > Behalf Of *Joe Baptista > *Sent:* Wednesday, January 13, 2010 5:19 PM > *To:* Christopher Mettin > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the > Gymnasium Querfurt High School to enhance education > > > > A very interesting development Christopher. But members reading this may be > confused. So will provide here a brief summary. > > Three days ago I faxed the Principle at Christopher's school the "Gymnasium > Querfurt High School" a letter and supporting documentation with respect to > Christopher's conduct in this conference - a copy of this fax is available > for members to read at the following URL: > > http://bit.ly/6q0r2g > > As a result of my letter meetings were held and the school is now doing its > best to distance itself from Christopher's projects. > > The school has confirmed with me that they will be replying to my fax by > letter. We will see then what they have to say. > > I do hope the school will apologize to the members here for Christopher's > conduct. > > And in closing I want to take this opportunity to ask Christopher in public > to apologize to the members for his conduct. I have asked Christopher in > private correspondence to apologize to the members. To date no apology has > been received and if Christopher can't provide one I hope the school does. > > > regards > joe baptista > > On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin < > cmettin at gqbc-online.com> wrote: > > Dear ARIN Community, > > > > To strengthen education of high school education, even outside the walls of > such an institution, in Mai 2008 the students of the Gymnasium Querfurt High > School founded the Gymnasium Querfurt Broadcasting Channel, an International > organization. It?s bylaws were soon written and meant to chronologically > include all future amendments and extensions to the mission of the > organizations, these bylaws are known as the GQ RFCs, in honor of the > Requests for Change. > > > > A few months afterwards the organizations was absorbed by the GQHS and > managed together with GQHS teachers. Three days ago from today, this action > was reversed together with our principal and the school assembly. The GQBC > administration, namely I, wanted to ensure the organization will be still > administrated according to its founding principles after my own graduation > and those of my fellow student network administrators. > > > > 3 official reasons were stated in the spin-off contract: > > 1. The fusion of GQBC with GQHS has never been authorized by a > ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC > growing in its first life phases; > > 2. GQ RFC 1 clearly stated that GQBC is an independent organization > with the mission to support education. To maintain objectivity such an > organization has to be run independently from a school. We only remained a > phrase advising that GQBC originated from the GQHS on our website, and also > GQBC will still provide services for the GQHS it provided before (e.g. web > transcripts); and > > 3. Due to massive email, fax, and even telephone fraud attacks by an > opponent of the Public-Root (name intentionally omitted but we are sure > everyone knows him), which already satisfy the definition of terrorism, and > the fact that GQ RFCs did never grant GQBC the right to provide contact > details of the GQHS to entities other than educational institutions. GQBC > amended its policies and the contact page on gqbc-online.com to state that > the only way for individuals and companies outside the state of > Sachsen-Anhalt to contact the school is through a spam-filtered email > address. > > > > It is entirely true that the attacker failed his goal to knock down the > development of a global school network (GQNET), and we can proudly say it > was not the fate of the pilot project for International education to fail. > The attacker will soon receive a message from our principal stating the > school is no longer responsible for his falsified claims and ?scam warnings? > and he will have to immediately stop to write any faxes, emails, or call the > school. > > > > GQNET which was planned within the last weeks is now ready to start. There > will be three main departments the network consists of: an Internet Service > provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET > domain management (GQ NIC), and the team re-deploying the internal GQHS > network to serve educational resources to the global GQNET (GQNET next-gen > school network). > > > > GQNET.Connect is hereby officially introduced as the first educational > Internet Service Provider with multi-homed deployment which will soon go on > with the work I began, making IP addresses available for educational > purposes free of charge. And of course, GQNET.Connect is primarily based in > Michigan), therefore subject to be served by ARIN with IP addresses. > > > > I hope we can soon find a way to get the important IP?s without long > discussions caused by commercial companies trying to reserve IP addresses > for their own prosper. The Web is an exponentially growing knowledge library > and not the stock market. > > > > For those of you who want to benefit from a more inclusive name space the > Public-Root, root of the Internet2 and our Top Level Domain sponsor, > provides, go on http://inaic.com to receive further information on how to > upgrade your desktop configurations and server hint files. Users of the > Public-Root have instant access to most GQNET resources. Further, the > Public-Root has master servers on all over the world and is therefore more > reliable than the commercial legacy root, which is mainly deployed on the > East and West coast of the US. > > > > Sincerely yours, > > Christopher Mettin > > Student Network Administrator > > GQBC > > > _______________________________________________ > 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 marty at akamai.com Wed Jan 13 20:05:46 2010 From: marty at akamai.com (Martin Hannigan) Date: Wed, 13 Jan 2010 20:05:46 -0500 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <4B4E5188.7020701@ipinc.net> References: <4B4E5188.7020701@ipinc.net> Message-ID: <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> On Jan 13, 2010, at 6:04 PM, Ted Mittelstaedt wrote: > marty at akamai.com wrote: > > On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: > > > >> marty at akamai.com wrote: > >>>> > > [ clip ] > >> How exactly is IANA held to ARIN's policies? ARIN could decide > that > >> IANA give all it's remaining IPv4 to ARIN, is IANA obligated to pay > >> attention to that? Seems to me your not going to get IANA to do > >> jack until any policy that affects it completes the GDP. > >> > >> Ted > >> > > Ted, > > > > Good question. Without a global policy, they aren?t. If you mean > to ask how > > that relationship is actually governed, you can see the documents > that > > codify the relationship and the global PDP by browsing here: > > http://www.nro.net/ > > > > Well, my question was more rhetorical - meaning that logically, since > these policies depend on IANA doing something, they really cannot > be policies until IANA agrees with them and follows them. I mean, we > can stick them in the ARIN policy manual and all that but they won't > be > followed until completion of GDP - so in essence, your statement that > > " they _are_ both ARIN region policies regardless " > > has no meaning. It's kind of like when the US Congress passes a law > then does not pass the finance bill that provides money to enforce the > law - thus, even though it's on the books, it effectively does not > exist. > > What I think is a much more interesting and relevant query is what > happens if either of these policies flunk out of the GDP? Does > ARIN's board then reverse their adoption and scrap them? > > Ted, I don't really know which is why I asked for clarification. I think, based on my reading, that the policy stands. Seems like a hole in both PDP's. Best, Martin From spiffnolee at yahoo.com Thu Jan 14 06:52:24 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 14 Jan 2010 03:52:24 -0800 (PST) Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> Message-ID: <776109.94295.qm@web63303.mail.re1.yahoo.com> > > > Good question. Without a global policy, they aren?t. If you mean to ask how > > > that relationship is actually governed, you can see the documents that > > > codify the relationship and the global PDP by browsing here: > > > http://www.nro.net/ > > > > > What I think is a much more interesting and relevant query is what > > happens if either of these policies flunk out of the GDP? Does > > ARIN's board then reverse their adoption and scrap them? > > > Ted, I don't really know which is why I asked for clarification. I think, based > on my reading, that the policy stands. Seems like a hole in both PDP's. Yes, we should clarify this. The NRO NC should clarify its process, and both the ARIN process and the status of global policy proposals within the ARIN region should be clearer. I'll see what we can do. Lee From marty at akamai.com Thu Jan 14 09:51:04 2010 From: marty at akamai.com (Martin Hannigan) Date: Thu, 14 Jan 2010 09:51:04 -0500 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <776109.94295.qm@web63303.mail.re1.yahoo.com> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <776109.94295.qm@web63303.mail.re1.yahoo.com> Message-ID: On Jan 14, 2010, at 6:52 AM, Lee Howard wrote: > > > > > > Good question. Without a global policy, they aren?t. If you > mean to ask how > > > > that relationship is actually governed, you can see the > documents that > > > > codify the relationship and the global PDP by browsing here: > > > > http://www.nro.net/ > > > > > > > What I think is a much more interesting and relevant query is what > > > happens if either of these policies flunk out of the GDP? Does > > > ARIN's board then reverse their adoption and scrap them? > > > > > Ted, I don't really know which is why I asked for clarification. I > think, based > > on my reading, that the policy stands. Seems like a hole in both > PDP's. > > Yes, we should clarify this. The NRO NC should clarify its process, > and > both the ARIN process and the status of global policy proposals > within the > ARIN region should be clearer. I'll see what we can do. > > Lee > > > > For all intents and purposes the global process is adequate. This is a regional issue. Dave Wilson (a participant in the RIPE Address Policy WG) identified this problem during the last RIPE meeting in Lisbon and has stated that he may introduce a policy proposal in the RIPE region to address it. If I remember correctly, Dave was thinking that there would be a pause with regards to the final acceptance in the region before formal ratification. This might be adequate to prevent a situation where we could be in a stranglehold. The pause might be a way to allow for any contextual adjustments that may need to be made to foster better cooperation. Best Regards, -M< From tedm at ipinc.net Thu Jan 14 11:56:19 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Jan 2010 08:56:19 -0800 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> Message-ID: <4B4F4CB3.7060507@ipinc.net> Martin Hannigan wrote: > > On Jan 13, 2010, at 6:04 PM, Ted Mittelstaedt wrote: > >> marty at akamai.com wrote: >> > On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: >> > >> >> marty at akamai.com wrote: >> >>>> >> >> > > [ clip ] > > >> >> How exactly is IANA held to ARIN's policies? ARIN could decide that >> >> IANA give all it's remaining IPv4 to ARIN, is IANA obligated to pay >> >> attention to that? Seems to me your not going to get IANA to do >> >> jack until any policy that affects it completes the GDP. >> >> >> >> Ted >> >> >> > Ted, >> > >> > Good question. Without a global policy, they aren?t. If you mean to >> ask how >> > that relationship is actually governed, you can see the documents that >> > codify the relationship and the global PDP by browsing here: >> > http://www.nro.net/ >> > >> >> Well, my question was more rhetorical - meaning that logically, since >> these policies depend on IANA doing something, they really cannot >> be policies until IANA agrees with them and follows them. I mean, we >> can stick them in the ARIN policy manual and all that but they won't be >> followed until completion of GDP - so in essence, your statement that >> >> " they _are_ both ARIN region policies regardless " >> >> has no meaning. It's kind of like when the US Congress passes a law >> then does not pass the finance bill that provides money to enforce the >> law - thus, even though it's on the books, it effectively does not >> exist. >> >> What I think is a much more interesting and relevant query is what >> happens if either of these policies flunk out of the GDP? Does >> ARIN's board then reverse their adoption and scrap them? >> >> > > > Ted, I don't really know which is why I asked for clarification. I > think, based on my reading, that the policy stands. I think your assuming that the ARIN board's adoption of global proposals changes the proposals into regional policies - and if they fail GDP that there's then a standoff between IANA and ARIN. I'm assuming that the ARIN board's adoption of the proposals is nothing more than an endorsement of them as proposals - because, until they are adopted as global policies, they remain global proposals. That was why Member Services put (Global Proposal) in parenthesis in front of them - since they are still proposals. Where I think the ambiguity exists is in the Member Services Announcement since at the beginning the paragraph states: "...adopted the following number resource policies:..." Then they go and list the "adopted policies" and mix up the now-policy additions with the still-global-proposal additions in the list that follows. It's definitely misleading to the casual observer. Ted From marty at akamai.com Thu Jan 14 11:58:24 2010 From: marty at akamai.com (Martin Hannigan) Date: Thu, 14 Jan 2010 11:58:24 -0500 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <4B4F4CB3.7060507@ipinc.net> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> Message-ID: On Jan 14, 2010, at 11:56 AM, Ted Mittelstaedt wrote: > Martin Hannigan wrote: > > > > On Jan 13, 2010, at 6:04 PM, Ted Mittelstaedt wrote: > > > >> marty at akamai.com wrote: > >> > On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: > >> > > >> >> marty at akamai.com wrote: > >> >>>> > >> > >> > > > > [ clip ] > > > > > >> >> How exactly is IANA held to ARIN's policies? ARIN could > decide that > >> >> IANA give all it's remaining IPv4 to ARIN, is IANA obligated > to pay > >> >> attention to that? Seems to me your not going to get IANA to do > >> >> jack until any policy that affects it completes the GDP. > >> >> > >> >> Ted > >> >> > >> > Ted, > >> > > >> > Good question. Without a global policy, they aren?t. If you > mean to > >> ask how > >> > that relationship is actually governed, you can see the > documents that > >> > codify the relationship and the global PDP by browsing here: > >> > http://www.nro.net/ > >> > > >> > >> Well, my question was more rhetorical - meaning that logically, > since > >> these policies depend on IANA doing something, they really cannot > >> be policies until IANA agrees with them and follows them. I > mean, we > >> can stick them in the ARIN policy manual and all that but they > won't be > >> followed until completion of GDP - so in essence, your statement > that > >> > >> " they _are_ both ARIN region policies regardless " > >> > >> has no meaning. It's kind of like when the US Congress passes a > law > >> then does not pass the finance bill that provides money to > enforce the > >> law - thus, even though it's on the books, it effectively does not > >> exist. > >> > >> What I think is a much more interesting and relevant query is what > >> happens if either of these policies flunk out of the GDP? Does > >> ARIN's board then reverse their adoption and scrap them? > >> > >> > > > > > > Ted, I don't really know which is why I asked for clarification. I > > think, based on my reading, that the policy stands. > > > I think your assuming that the ARIN board's adoption of global > proposals > changes the proposals into regional policies - and if they fail GDP > that > there's then a standoff between IANA and ARIN. > I'm not making any assumptions at all. The proposal went into the standard policy process and came out the other side as a policy. It is that straight forward. And I think that Lee Howard seems to have confirmed that. Best, -M< From tedm at ipinc.net Thu Jan 14 12:23:11 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Jan 2010 09:23:11 -0800 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> Message-ID: <4B4F52FF.6010805@ipinc.net> Martin Hannigan wrote: > > On Jan 14, 2010, at 11:56 AM, Ted Mittelstaedt wrote: > >> Martin Hannigan wrote: >> > >> > On Jan 13, 2010, at 6:04 PM, Ted Mittelstaedt wrote: >> > >> >> marty at akamai.com wrote: >> >> > On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: >> >> > >> >> >> marty at akamai.com wrote: >> >> >>>> >> >> >> >> >> > >> > [ clip ] >> > >> > >> >> >> How exactly is IANA held to ARIN's policies? ARIN could decide >> that >> >> >> IANA give all it's remaining IPv4 to ARIN, is IANA obligated to pay >> >> >> attention to that? Seems to me your not going to get IANA to do >> >> >> jack until any policy that affects it completes the GDP. >> >> >> >> >> >> Ted >> >> >> >> >> > Ted, >> >> > >> >> > Good question. Without a global policy, they aren?t. If you mean to >> >> ask how >> >> > that relationship is actually governed, you can see the documents >> that >> >> > codify the relationship and the global PDP by browsing here: >> >> > http://www.nro.net/ >> >> > >> >> >> >> Well, my question was more rhetorical - meaning that logically, since >> >> these policies depend on IANA doing something, they really cannot >> >> be policies until IANA agrees with them and follows them. I mean, we >> >> can stick them in the ARIN policy manual and all that but they >> won't be >> >> followed until completion of GDP - so in essence, your statement that >> >> >> >> " they _are_ both ARIN region policies regardless " >> >> >> >> has no meaning. It's kind of like when the US Congress passes a law >> >> then does not pass the finance bill that provides money to enforce the >> >> law - thus, even though it's on the books, it effectively does not >> >> exist. >> >> >> >> What I think is a much more interesting and relevant query is what >> >> happens if either of these policies flunk out of the GDP? Does >> >> ARIN's board then reverse their adoption and scrap them? >> >> >> >> >> > >> > >> > Ted, I don't really know which is why I asked for clarification. I >> > think, based on my reading, that the policy stands. >> >> >> I think your assuming that the ARIN board's adoption of global proposals >> changes the proposals into regional policies - and if they fail GDP that >> there's then a standoff between IANA and ARIN. >> > > I'm not making any assumptions at all. The proposal went into the > standard policy process and came out the other side as a policy. It is > that straight forward. And I think that Lee Howard seems to have > confirmed that. > Lee's statement was "...status of global policy PROPOSALS within the ARIN region..." The strong implication there is that these proposals are still proposals at this time. But I suspect Lee's hedging a bit himself, right now. I would!!! :-) Ted > Best, > > -M< > > > > From marty at akamai.com Thu Jan 14 12:31:51 2010 From: marty at akamai.com (Martin Hannigan) Date: Thu, 14 Jan 2010 12:31:51 -0500 Subject: [arin-ppml] =?iso-8859-1?q?NRPM_2010=2E1_=AD_New_Policies_Impleme?= =?iso-8859-1?q?nted?= In-Reply-To: <4B4F52FF.6010805@ipinc.net> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> <4B4F52FF.6010805@ipinc.net> Message-ID: <38DBE528-5ECD-4578-9BCD-64B86D8BB72E@akamai.com> On Jan 14, 2010, at 12:23 PM, Ted Mittelstaedt wrote: > Martin Hannigan wrote: > > > > On Jan 14, 2010, at 11:56 AM, Ted Mittelstaedt wrote: > > > >> Martin Hannigan wrote: > >> > > >> > On Jan 13, 2010, at 6:04 PM, Ted Mittelstaedt wrote: > >> > > >> >> marty at akamai.com wrote: > >> >> > On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: > >> >> > > >> >> >> marty at akamai.com wrote: > >> >> >>>> > >> >> > >> >> > >> > > >> > [ clip ] > >> > > >> > > >> >> >> How exactly is IANA held to ARIN's policies? ARIN could > decide > >> that > >> >> >> IANA give all it's remaining IPv4 to ARIN, is IANA > obligated to pay > >> >> >> attention to that? Seems to me your not going to get IANA > to do > >> >> >> jack until any policy that affects it completes the GDP. > >> >> >> > >> >> >> Ted > >> >> >> > >> >> > Ted, > >> >> > > >> >> > Good question. Without a global policy, they aren?t. If you > mean to > >> >> ask how > >> >> > that relationship is actually governed, you can see the > documents > >> that > >> >> > codify the relationship and the global PDP by browsing here: > >> >> > http://www.nro.net/ > >> >> > > >> >> > >> >> Well, my question was more rhetorical - meaning that > logically, since > >> >> these policies depend on IANA doing something, they really > cannot > >> >> be policies until IANA agrees with them and follows them. I > mean, we > >> >> can stick them in the ARIN policy manual and all that but they > >> won't be > >> >> followed until completion of GDP - so in essence, your > statement that > >> >> > >> >> " they _are_ both ARIN region policies regardless " > >> >> > >> >> has no meaning. It's kind of like when the US Congress passes > a law > >> >> then does not pass the finance bill that provides money to > enforce the > >> >> law - thus, even though it's on the books, it effectively does > not > >> >> exist. > >> >> > >> >> What I think is a much more interesting and relevant query is > what > >> >> happens if either of these policies flunk out of the GDP? Does > >> >> ARIN's board then reverse their adoption and scrap them? > >> >> > >> >> > >> > > >> > > >> > Ted, I don't really know which is why I asked for > clarification. I > >> > think, based on my reading, that the policy stands. > >> > >> > >> I think your assuming that the ARIN board's adoption of global > proposals > >> changes the proposals into regional policies - and if they fail > GDP that > >> there's then a standoff between IANA and ARIN. > >> > > > > I'm not making any assumptions at all. The proposal went into the > > standard policy process and came out the other side as a policy. > It is > > that straight forward. And I think that Lee Howard seems to have > > confirmed that. > > > > Lee's statement was > > "...status of global policy PROPOSALS within the ARIN region..." > > The strong implication there is that these proposals are still > proposals > at this time. > > But I suspect Lee's hedging a bit himself, right now. I would!!! :-) > > Ted > > Ted, Seems like it's written in English: --snarf From: info at arin.net Subject: [arin-ppml] NRPM 2010.1 ? New Policies Implemented Date: January 13, 2010 3:06:26 PM EST To: arin-ppml at arin.net "On 18 December 2009 the ARIN Board of Trustees, based on the recommendation of the Advisory Council and noting that the Policy Development Process had been followed, adopted the following number resource policies: [ clip [ 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries" --ex snarf Nothing in the ARIN PDP says 'just kidding' in the event that the global part of the proposal fails. Thoughts? -M< From tedm at ipinc.net Thu Jan 14 13:10:22 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Jan 2010 10:10:22 -0800 Subject: [arin-ppml] =?windows-1252?q?NRPM_2010=2E1_=AD_New_Policies_Imple?= =?windows-1252?q?mented?= In-Reply-To: <38DBE528-5ECD-4578-9BCD-64B86D8BB72E@akamai.com> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> <4B4F52FF.6010805@ipinc.net> <38DBE528-5ECD-4578-9BCD-64B86D8BB72E@akamai.com> Message-ID: <4B4F5E0E.9020009@ipinc.net> Martin Hannigan wrote: > > On Jan 14, 2010, at 12:23 PM, Ted Mittelstaedt wrote: > >> Martin Hannigan wrote: >> > >> > On Jan 14, 2010, at 11:56 AM, Ted Mittelstaedt wrote: >> > >> >> Martin Hannigan wrote: >> >> > >> >> > On Jan 13, 2010, at 6:04 PM, Ted Mittelstaedt wrote: >> >> > >> >> >> marty at akamai.com wrote: >> >> >> > On 1/13/10 3:44 PM, "Ted Mittelstaedt" wrote: >> >> >> > >> >> >> >> marty at akamai.com wrote: >> >> >> >>>> >> >> >> >> >> >> >> >> > >> >> > [ clip ] >> >> > >> >> > >> >> >> >> How exactly is IANA held to ARIN's policies? ARIN could decide >> >> that >> >> >> >> IANA give all it's remaining IPv4 to ARIN, is IANA obligated >> to pay >> >> >> >> attention to that? Seems to me your not going to get IANA to do >> >> >> >> jack until any policy that affects it completes the GDP. >> >> >> >> >> >> >> >> Ted >> >> >> >> >> >> >> > Ted, >> >> >> > >> >> >> > Good question. Without a global policy, they aren?t. If you >> mean to >> >> >> ask how >> >> >> > that relationship is actually governed, you can see the documents >> >> that >> >> >> > codify the relationship and the global PDP by browsing here: >> >> >> > http://www.nro.net/ >> >> >> > >> >> >> >> >> >> Well, my question was more rhetorical - meaning that logically, >> since >> >> >> these policies depend on IANA doing something, they really cannot >> >> >> be policies until IANA agrees with them and follows them. I >> mean, we >> >> >> can stick them in the ARIN policy manual and all that but they >> >> won't be >> >> >> followed until completion of GDP - so in essence, your statement >> that >> >> >> >> >> >> " they _are_ both ARIN region policies regardless " >> >> >> >> >> >> has no meaning. It's kind of like when the US Congress passes a >> law >> >> >> then does not pass the finance bill that provides money to >> enforce the >> >> >> law - thus, even though it's on the books, it effectively does not >> >> >> exist. >> >> >> >> >> >> What I think is a much more interesting and relevant query is what >> >> >> happens if either of these policies flunk out of the GDP? Does >> >> >> ARIN's board then reverse their adoption and scrap them? >> >> >> >> >> >> >> >> > >> >> > >> >> > Ted, I don't really know which is why I asked for clarification. I >> >> > think, based on my reading, that the policy stands. >> >> >> >> >> >> I think your assuming that the ARIN board's adoption of global >> proposals >> >> changes the proposals into regional policies - and if they fail GDP >> that >> >> there's then a standoff between IANA and ARIN. >> >> >> > >> > I'm not making any assumptions at all. The proposal went into the >> > standard policy process and came out the other side as a policy. It is >> > that straight forward. And I think that Lee Howard seems to have >> > confirmed that. >> > >> >> Lee's statement was >> >> "...status of global policy PROPOSALS within the ARIN region..." >> >> The strong implication there is that these proposals are still proposals >> at this time. >> >> But I suspect Lee's hedging a bit himself, right now. I would!!! :-) >> >> Ted >> >> > > > Ted, > > Seems like it's written in English: > > --snarf > > From: info at arin.net > Subject: [arin-ppml] NRPM 2010.1 ? New Policies Implemented > > Date: January 13, 2010 3:06:26 PM EST > > To: arin-ppml at arin.net > > "On 18 December 2009 the ARIN Board of Trustees, based on the > recommendation of the Advisory Council and noting that the Policy > Development Process had been followed, adopted the following number > resource policies: > > [ clip [ > > 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) > Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries" > > --ex snarf > > Nothing in the ARIN PDP says 'just kidding' in the event that the global > part of the proposal fails. > > Thoughts? > Going back to what I said originally, ARIN (or any other RIR) can adopt all the policies they want that says IANA do this, IANA do that - but IANA ain't gonna do squat unless a policy proposal is adopted though the GDP Personally, I think the biggest problem is this rubbish about having the RIR adopt a global policy first, then sending it on to IANA. I've always thought that was bass-ackwards. This situation is almost spot-on identical to the disaster that was the 1972 US Equal Rights Amendment. Imagine the millions of dollars thrown into that campaign where almost the entire country's state legislatures ratified it then the thing was scotched, shy of 3 states - leaving dozens of states in legal limbo - since how in the hell does a state government that passed ERA then turn around and argue against an equivalent ERA to it's own state constitution? As a matter of fact IT CAN'T since 16 of those states then turned around and added it in to their state constitutions. As a result, in the US today, we have half of the country that has ERA as state law, (21 states) and half of the country that does not, with the feds still dithering around about it. Ted From info at arin.net Thu Jan 14 18:06:07 2010 From: info at arin.net (Member Services) Date: Thu, 14 Jan 2010 18:06:07 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria Message-ID: <4B4FA35F.9070804@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 107: Rework of IPv6 assignment criteria Proposal Originator: David Farmer Proposal Version: 1.0 Date: 1/14/2010 Proposal type: modify Policy term: Permanent Policy statement: 6.5.8. Initial assignments 6.5.8.1. Initial assignment size Organizations that meet at least one of the following criteria are eligible to receive a minimum assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the 0.94 HD-Ratio metric. All assignments shall be made from distinctly identified prefixes, with each assignment receiving a reservation for growth of at least a /44. Such reservations are not guaranteed and ARIN, at its discretion, may assign them to other organizations at any time. 6.5.8.2. Criteria for initial assignment to Internet connected end-users Organizations may justify an initial assignment for connecting their own network to the IPv6 Internet, with an intent to provide global reachability for the assignment within 12 months, and for addressing devices directly attached to their network infrastructure, by meeting one of the following additional criteria. a. Having a previously justified IPv4 end-users assignment from ARIN or one of its predecessor registries, or; b. Multihoming using an assigned Autonomous System Number (ASN), or; c. By providing a reasonable technical justification indicating why other IPv6 addresses from an ISP or other LIR are unsuitable and a plan detailing the utilization of subnets for one, two and five year periods. 6.5.8.3 Criteria for initial assignment to non-connected networks Organizations are encouraged to consider the use of Unique Local IPv6 Unicast Addresses (ULA, See RFC 4193) for a network that is not currently connected and/or planning not to connect to the Internet. Not withstanding this, organizations may justify an initial assignment for operating their own non-connected IPv6 network and for addressing devices directly attached to their network infrastructure, by meeting one of the following additional criteria. a. Having a previously justified IPv4 end-users assignment from ARIN or one of its predecessor registries, or; b. By providing a reasonable technical justification indicating why an assignment for a non-connected networks is necessary, including the intended purpose for the assignment, and describing the network infrastructure the assignment will be used to support. Justification must include why ULA IPv6 addresses are unsuitable and a plan detailing the utilization of subnets for one, two and five year periods. 6.5.8.4 Criteria for initial assignment to Community Networks Organizations may justify an initial assignment for operating a Community Network only for the purpose of providing free or low-cost internet connectivity to the residents of their local service area. By documenting the service area they intend to serve, certifying that the community network staff is 100% volunteers, and otherwise meeting the definition of a Community Network. 6.5.9. Subsequent assignments Subsequent assignments may be made when the need for additional subnets are justified. Justification will be determined based on the 0.94 HD-Ratio metric. When possible, subsequent assignments will be made from an adjacent address block. Delete current 6.5.9 Community Network Assignments as it is incorporated in 6.5.8.4. Rationale: This proposal provides a complete rework of the IPv6 end-user assignment criteria, removing the dependency on IPv4 policy, while maintaining many of the basic concepts contained in the current policies. The order of the subsections of 6.5.8 was rearranged moving the initial assignment size to 6.5.8.1 and subsequent assignments to 6.5.9. This will facilitate adding future criteria without additional renumbering of current policies. The initial assignment criteria include the following general concepts; ? When Internet connectivity is use to justify resources it is implied the resources should be advertised to the Internet, within some reasonable time frame after they are received. ? IPv4 resources may be use to justify the need for IPv6 resources. ? Internet multihoming is sufficient justification for an end-user assignment in and of itself. ? Other end-users must justify why an ISP or LIR assignment is not sufficient for their needs. ? Non-connected networks must describe the purpose and network infrastructure the assignment will be supporting, including why ULA is not sufficient for their needs. ? Community networks are assumed to justify an assignment in and of themselves. Timetable for implementation: Immediate From spiffnolee at yahoo.com Fri Jan 15 11:43:13 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 15 Jan 2010 08:43:13 -0800 (PST) Subject: [arin-ppml] =?iso-8859-1?q?Global_policy_development_process_=5Bw?= =?iso-8859-1?q?as=3A_Re=3A__NRPM_2010=2E1_=AD_New_Policies_Implemented=5D?= In-Reply-To: <4B4F52FF.6010805@ipinc.net> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> <4B4F52FF.6010805@ipinc.net> Message-ID: <247103.78548.qm@web63307.mail.re1.yahoo.com> > Lee's statement was > > "...status of global policy PROPOSALS within the ARIN region..." > > The strong implication there is that these proposals are still proposals > at this time. > > But I suspect Lee's hedging a bit himself, right now. I would!!! :-) Me, hedge? Never! Well, hardly ever. ;-) I don't know if the process is wrong, but since people are debating about what it actually IS, I think it's unclear. What do you think the process for global policy development SHOULD be? Thanks, Lee From bicknell at ufp.org Fri Jan 15 11:56:00 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Jan 2010 08:56:00 -0800 Subject: [arin-ppml] Global policy development process [was: Re: NRPM 2010.1 ? New Policies Implemented] In-Reply-To: <247103.78548.qm@web63307.mail.re1.yahoo.com> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> <4B4F52FF.6010805@ipinc.net> <247103.78548.qm@web63307.mail.re1.yahoo.com> Message-ID: <20100115165600.GA98382@ussenterprise.ufp.org> In a message written on Fri, Jan 15, 2010 at 08:43:13AM -0800, Lee Howard wrote: > What do you think the process for global policy development SHOULD be? I have said before: ARIN should have a process similar to, but separate from the PDP for "speaking". That is, we should be able to pass a resolution like: "ARIN requests IANA to assign ASN's according to the following criteria....." It makes no sense for such a thing to be put in our PDP, as there is nothing for ARIN to do. It makes no sense to use the PDP process, because each step (e.g. staff impact) is predicated on ARIN staff doing something. It also makes no sense to list these things in the PDP. For instance, we pass it and the other 4 RIR's do not, it does not become IANA policy, but it is stuck in our PDP until we go remove it. So we publish it on the web as if it is policy, confusing everyone. Once all 5 RIR's make a formal request like the example above, IANA could say: "All 5 RIR's have requested ASN's be assigned by the following critera...." "As a result, the criteria above has been added to IANA policy ABC.123, and will be implemented by IANA on Jan 1 ABCD." So it's pretty much exactly the same structure, but we stop calling a request to IANA an ARIN policy, because, well, it isn't, and it confuses everyone. I can think of no more damning condemnation of the current process than the fact that Mr Hannigan is asking the question, someone who is currently on the ICANN ASO AC. If someone who is the next step in the process can't understand what in the heck we're doing then there's no way for the average Joe to keep track. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dylan.ebner at crlmed.com Fri Jan 15 12:00:49 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 15 Jan 2010 17:00:49 +0000 Subject: [arin-ppml] Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education In-Reply-To: <874c02a21001131551x5ff9b4d8j24ba74fb32b7155b@mail.gmail.com> References: <874c02a21001131551x5ff9b4d8j24ba74fb32b7155b@mail.gmail.com> Message-ID: <017265BF3B9640499754DD48777C3D2067176803D0@MBX9.EXCHPROD.USA.NET> Joe- Please let me complement you on your level of compassion for Mr. Mettin's image and his future throughout this incident. Although I have never met you, you sound like a good person. Your willingness to defend one who has defamed upon you is a testament to your nature. As you have been the one harmed in this incident, your preferences on how the ARIN community should be considered above the other members, and I respectfully defer my request to you and wait for your recommendation. However, as you pointed out, everything here is archived forever and with this issue dragging on we must also consider the ARIN community as a whole and it's ability to resolve conflicts. I worry that this whole issue, and others like it that may come up, may damage the ARIN reputation if ARIN cannot resolve these types of conflicts quickly and efficiently. These things ultimately are distractions to the business at hand. My request was simply made because Mr. Mettin, even though he had already been warned about his behaviour by ARIN, continued his behaviour. We have all in times of frustration and annoyance posted non-professional statements to public mailing lists. This is human nature. Sometimes we say something we don't mean. Usually, we come to regret our statements and many times appologize privately or publicly for our remarks. Mr. Mettin has not only not shown he is unwilling to retract his statements, he has continued making slanderous statements against you. It is my opinion that if ARIN does not deal with this type of behaviour in accordance with the rules, then we are ultimately degrading the quality of the ARIN mailing list and it's image in the Internet community. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com ________________________________________ From: publicroot.info at gmail.com [publicroot.info at gmail.com] On Behalf Of Joe Baptista [baptista at publicroot.org] Sent: Wednesday, January 13, 2010 5:51 PM To: Dylan Ebner Cc: Christopher Mettin; arin-ppml at arin.net Subject: Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education I will not oppose the removal of Mr. Mettin this time. I don't care how old you are. I'm not a big fan of baseball so I don't believe in the three strikes rule. I'm into the one strike rule. But I appeal to the AUP Committee to please not be hasty in making a decision. I have been promised a reply at least from the school in which they will address the members. I also remind the committee and the members here that it is I who am being liable, slandered and defamed here. I therefore reserve the right to submit for the consideration of the AUP committee a representation concerning this matter. Let us not forget who you are. ARIN is an internationally respected organization. You are about to cause damage to the reputation of an 18 year old boy. All these matters are forever archived. And I don't think Christopher is completely at fault here. I think a good portion of the fault lies with his school the Gymnasium Querfurt. This boy is a victim. Both I and Christopher got involved in the INAIC Public-Root scandal. I'm an insider and even I didn't know about the fraud until I investigated in the Netherlands. It's not the boys fault that he went a little nutty trying to defend them. Again the fault is with the school. Where was the supervision? Also I point out to the AUP Committee the school is responsible for his activities and statements here. I want to see how the Gymnasium Querfurt wiggles out of that. But also they only found out about this when I faxed them some three days ago. They had no idea what was going on. I tried emailing them but Christopher has been filtering the schools email. You may remember he said so in his Spin-Off notice to ARIN-PPML. Thats another issue. He admitted he hijacked the schools email system - does the school even know? This may even be a criminal issue in Germany. But the bottom line here is that the school must share responsibility for Christopher's actions. I therefore would like some time to prepare a statement to submit to the committee. Thanks joe baptista the injured party On Wed, Jan 13, 2010 at 4:12 PM, Dylan Ebner > wrote: I think Mt. Mettin?s statement, ?If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then.?, qualifies as violating the ARIN prohibited activities section 1, ?Statements that include foul language, personal character attacks, or show disrespect for other participants, including ARIN.? Can we please remove Mr. Mettin and get on with more important business? This is getting old. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Wednesday, January 13, 2010 10:57 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Oh, someone admitting his guilt. I was counting on that. Yep, that?s the guy who was wasting our limited school paper. 4 week days in a row we received faxes (the one he linked was only the second one) containing falsified claims and crazy threats. This behavior violates the United States Code (don?t ask me for the exact section and clause). If they don?t stop contacting our school immediately, we will take legal actions. If anyone googles up, they will find a dozen of emails and faxes he sent to government offices and non-commercial organizations. It is also a falsification to identify oneself as a member of an organization that fired one and now tries to convince other people to not work with this company (as Mr. Baptista does). Is advised to ignore Mr. Baptista as everyone of the other affected people did. If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then. No further comments requested. From: publicroot.info@gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Wednesday, January 13, 2010 5:19 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education A very interesting development Christopher. But members reading this may be confused. So will provide here a brief summary. Three days ago I faxed the Principle at Christopher's school the "Gymnasium Querfurt High School" a letter and supporting documentation with respect to Christopher's conduct in this conference - a copy of this fax is available for members to read at the following URL: http://bit.ly/6q0r2g As a result of my letter meetings were held and the school is now doing its best to distance itself from Christopher's projects. The school has confirmed with me that they will be replying to my fax by letter. We will see then what they have to say. I do hope the school will apologize to the members here for Christopher's conduct. And in closing I want to take this opportunity to ask Christopher in public to apologize to the members for his conduct. I have asked Christopher in private correspondence to apologize to the members. To date no apology has been received and if Christopher can't provide one I hope the school does. regards joe baptista On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin > wrote: Dear ARIN Community, To strengthen education of high school education, even outside the walls of such an institution, in Mai 2008 the students of the Gymnasium Querfurt High School founded the Gymnasium Querfurt Broadcasting Channel, an International organization. It?s bylaws were soon written and meant to chronologically include all future amendments and extensions to the mission of the organizations, these bylaws are known as the GQ RFCs, in honor of the Requests for Change. A few months afterwards the organizations was absorbed by the GQHS and managed together with GQHS teachers. Three days ago from today, this action was reversed together with our principal and the school assembly. The GQBC administration, namely I, wanted to ensure the organization will be still administrated according to its founding principles after my own graduation and those of my fellow student network administrators. 3 official reasons were stated in the spin-off contract: 1. The fusion of GQBC with GQHS has never been authorized by a ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC growing in its first life phases; 2. GQ RFC 1 clearly stated that GQBC is an independent organization with the mission to support education. To maintain objectivity such an organization has to be run independently from a school. We only remained a phrase advising that GQBC originated from the GQHS on our website, and also GQBC will still provide services for the GQHS it provided before (e.g. web transcripts); and 3. Due to massive email, fax, and even telephone fraud attacks by an opponent of the Public-Root (name intentionally omitted but we are sure everyone knows him), which already satisfy the definition of terrorism, and the fact that GQ RFCs did never grant GQBC the right to provide contact details of the GQHS to entities other than educational institutions. GQBC amended its policies and the contact page on gqbc-online.com to state that the only way for individuals and companies outside the state of Sachsen-Anhalt to contact the school is through a spam-filtered email address. It is entirely true that the attacker failed his goal to knock down the development of a global school network (GQNET), and we can proudly say it was not the fate of the pilot project for International education to fail. The attacker will soon receive a message from our principal stating the school is no longer responsible for his falsified claims and ?scam warnings? and he will have to immediately stop to write any faxes, emails, or call the school. GQNET which was planned within the last weeks is now ready to start. There will be three main departments the network consists of: an Internet Service provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET domain management (GQ NIC), and the team re-deploying the internal GQHS network to serve educational resources to the global GQNET (GQNET next-gen school network). GQNET.Connect is hereby officially introduced as the first educational Internet Service Provider with multi-homed deployment which will soon go on with the work I began, making IP addresses available for educational purposes free of charge. And of course, GQNET.Connect is primarily based in Michigan), therefore subject to be served by ARIN with IP addresses. I hope we can soon find a way to get the important IP?s without long discussions caused by commercial companies trying to reserve IP addresses for their own prosper. The Web is an exponentially growing knowledge library and not the stock market. For those of you who want to benefit from a more inclusive name space the Public-Root, root of the Internet2 and our Top Level Domain sponsor, provides, go on http://inaic.com to receive further information on how to upgrade your desktop configurations and server hint files. Users of the Public-Root have instant access to most GQNET resources. Further, the Public-Root has master servers on all over the world and is therefore more reliable than the commercial legacy root, which is mainly deployed on the East and West coast of the US. Sincerely yours, Christopher Mettin Student Network Administrator GQBC _______________________________________________ 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 bill at herrin.us Fri Jan 15 12:06:42 2010 From: bill at herrin.us (William Herrin) Date: Fri, 15 Jan 2010 12:06:42 -0500 Subject: [arin-ppml] =?iso-8859-1?q?Global_policy_development_process_=5Bw?= =?iso-8859-1?q?as=3A_Re=3A_NRPM_2010=2E1_=AD_New_Policies_Implemen?= =?iso-8859-1?q?ted=5D?= In-Reply-To: <247103.78548.qm@web63307.mail.re1.yahoo.com> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> <4B4F52FF.6010805@ipinc.net> <247103.78548.qm@web63307.mail.re1.yahoo.com> Message-ID: <3c3e3fca1001150906v3051ba8cw28791b1d9c1c61ae@mail.gmail.com> On Fri, Jan 15, 2010 at 11:43 AM, Lee Howard wrote: > I don't know if the process is wrong, but since people are debating about > what it actually IS, I think it's unclear. > > What do you think the process for global policy development SHOULD be? Lee, My knee-jerk reaction is: First draft in one region. Second draft in all regions (either cross-posted or some sort of joint global policy list). Formal request for adoption from one region. All regions accept or reject it as written. The proposal is not adopted in any region until it accepted in all. Each binding global policy is written in only one language, regardless of region. Translations for convenience are non-binding. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gqnet.connect at gqnn.net Fri Jan 15 12:17:53 2010 From: gqnet.connect at gqnn.net (GQNN.Connect) Date: Fri, 15 Jan 2010 18:17:53 +0100 Subject: [arin-ppml] FW: Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Message-ID: -----Original Message----- From: Christopher Mettin [mailto:cmettin at gqbc-online.com] Sent: Friday, January 15, 2010 6:17 PM To: 'Dylan Ebner' Subject: FW: Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education You are superficial, aren't you? I hate superficial people. This guy is a terrorist, he should be excluded from the mailing list. He has been starting with his falsified claims and "scam warnings" in early December and no one has been saying anything. Are you so damn superficial or what's up? There is an email in the attachment I have been sending to the mailing list, not sure whether it ever appeared. But if you carefully read his website, you see what the scam is. And I just found out, there is any page that says he has the developed the "Casedian Root" and features a link to this "root", and when you click on it, an advertisement/parking page appears. Faxes over faxes, we received another one just yesterday, he forwarded the mailing list messages to the school office. Everyone just laughed about this idiot but actually it's a waste of paper, which is limited by state regulations. He is no good person at all. Did you read this "the injured party" under his name, crazy, ain't he? In what way has he been injured? Read this article on him: http://inaic.com/index.php?p=internet-terror, then you know in short what he has done. But something that this article does not say is that he uses the CNN logo for his own evil purposes on his website (see my email attachment). I think that says everything. Christopher -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Friday, January 15, 2010 6:01 PM To: Joe Baptista Cc: Christopher Mettin; arin-ppml at arin.net Subject: RE: Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Joe- Please let me complement you on your level of compassion for Mr. Mettin's image and his future throughout this incident. Although I have never met you, you sound like a good person. Your willingness to defend one who has defamed upon you is a testament to your nature. As you have been the one harmed in this incident, your preferences on how the ARIN community should be considered above the other members, and I respectfully defer my request to you and wait for your recommendation. However, as you pointed out, everything here is archived forever and with this issue dragging on we must also consider the ARIN community as a whole and it's ability to resolve conflicts. I worry that this whole issue, and others like it that may come up, may damage the ARIN reputation if ARIN cannot resolve these types of conflicts quickly and efficiently. These things ultimately are distractions to the business at hand. My request was simply made because Mr. Mettin, even though he had already been warned about his behaviour by ARIN, continued his behaviour. We have all in times of frustration and annoyance posted non-professional statements to public mailing lists. This is human nature. Sometimes we say something we don't mean. Usually, we come to regret our statements and many times appologize privately or publicly for our remarks. Mr. Mettin has not only not shown he is unwilling to retract his statements, he has continued making slanderous statements against you. It is my opinion that if ARIN does not deal with this type of behaviour in accordance with the rules, then we are ultimately degrading the quality of the ARIN mailing list and it's image in the Internet community. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com ________________________________________ From: publicroot.info at gmail.com [publicroot.info at gmail.com] On Behalf Of Joe Baptista [baptista at publicroot.org] Sent: Wednesday, January 13, 2010 5:51 PM To: Dylan Ebner Cc: Christopher Mettin; arin-ppml at arin.net Subject: Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education I will not oppose the removal of Mr. Mettin this time. I don't care how old you are. I'm not a big fan of baseball so I don't believe in the three strikes rule. I'm into the one strike rule. But I appeal to the AUP Committee to please not be hasty in making a decision. I have been promised a reply at least from the school in which they will address the members. I also remind the committee and the members here that it is I who am being liable, slandered and defamed here. I therefore reserve the right to submit for the consideration of the AUP committee a representation concerning this matter. Let us not forget who you are. ARIN is an internationally respected organization. You are about to cause damage to the reputation of an 18 year old boy. All these matters are forever archived. And I don't think Christopher is completely at fault here. I think a good portion of the fault lies with his school the Gymnasium Querfurt. This boy is a victim. Both I and Christopher got involved in the INAIC Public-Root scandal. I'm an insider and even I didn't know about the fraud until I investigated in the Netherlands. It's not the boys fault that he went a little nutty trying to defend them. Again the fault is with the school. Where was the supervision? Also I point out to the AUP Committee the school is responsible for his activities and statements here. I want to see how the Gymnasium Querfurt wiggles out of that. But also they only found out about this when I faxed them some three days ago. They had no idea what was going on. I tried emailing them but Christopher has been filtering the schools email. You may remember he said so in his Spin-Off notice to ARIN-PPML. Thats another issue. He admitted he hijacked the schools email system - does the school even know? This may even be a criminal issue in Germany. But the bottom line here is that the school must share responsibility for Christopher's actions. I therefore would like some time to prepare a statement to submit to the committee. Thanks joe baptista the injured party On Wed, Jan 13, 2010 at 4:12 PM, Dylan Ebner > wrote: I think Mt. Mettin's statement, "If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then.", qualifies as violating the ARIN prohibited activities section 1, "Statements that include foul language, personal character attacks, or show disrespect for other participants, including ARIN." Can we please remove Mr. Mettin and get on with more important business? This is getting old. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Wednesday, January 13, 2010 10:57 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Oh, someone admitting his guilt. I was counting on that. Yep, that's the guy who was wasting our limited school paper. 4 week days in a row we received faxes (the one he linked was only the second one) containing falsified claims and crazy threats. This behavior violates the United States Code (don't ask me for the exact section and clause). If they don't stop contacting our school immediately, we will take legal actions. If anyone googles up, they will find a dozen of emails and faxes he sent to government offices and non-commercial organizations. It is also a falsification to identify oneself as a member of an organization that fired one and now tries to convince other people to not work with this company (as Mr. Baptista does). Is advised to ignore Mr. Baptista as everyone of the other affected people did. If Mr. Baptista thinks he knows better about our internal school business, he can go tell his grandma, uh, no, I forgot he lives with his Mama, maybe she will still pay the next Internet bill then. No further comments requested. From: publicroot.info@gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Wednesday, January 13, 2010 5:19 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education A very interesting development Christopher. But members reading this may be confused. So will provide here a brief summary. Three days ago I faxed the Principle at Christopher's school the "Gymnasium Querfurt High School" a letter and supporting documentation with respect to Christopher's conduct in this conference - a copy of this fax is available for members to read at the following URL: http://bit.ly/6q0r2g As a result of my letter meetings were held and the school is now doing its best to distance itself from Christopher's projects. The school has confirmed with me that they will be replying to my fax by letter. We will see then what they have to say. I do hope the school will apologize to the members here for Christopher's conduct. And in closing I want to take this opportunity to ask Christopher in public to apologize to the members for his conduct. I have asked Christopher in private correspondence to apologize to the members. To date no apology has been received and if Christopher can't provide one I hope the school does. regards joe baptista On Wed, Jan 13, 2010 at 10:36 AM, Christopher Mettin > wrote: Dear ARIN Community, To strengthen education of high school education, even outside the walls of such an institution, in Mai 2008 the students of the Gymnasium Querfurt High School founded the Gymnasium Querfurt Broadcasting Channel, an International organization. It's bylaws were soon written and meant to chronologically include all future amendments and extensions to the mission of the organizations, these bylaws are known as the GQ RFCs, in honor of the Requests for Change. A few months afterwards the organizations was absorbed by the GQHS and managed together with GQHS teachers. Three days ago from today, this action was reversed together with our principal and the school assembly. The GQBC administration, namely I, wanted to ensure the organization will be still administrated according to its founding principles after my own graduation and those of my fellow student network administrators. 3 official reasons were stated in the spin-off contract: 1. The fusion of GQBC with GQHS has never been authorized by a ratified GQ RFC. GQHS rather received a temporary mandate to help GQBC growing in its first life phases; 2. GQ RFC 1 clearly stated that GQBC is an independent organization with the mission to support education. To maintain objectivity such an organization has to be run independently from a school. We only remained a phrase advising that GQBC originated from the GQHS on our website, and also GQBC will still provide services for the GQHS it provided before (e.g. web transcripts); and 3. Due to massive email, fax, and even telephone fraud attacks by an opponent of the Public-Root (name intentionally omitted but we are sure everyone knows him), which already satisfy the definition of terrorism, and the fact that GQ RFCs did never grant GQBC the right to provide contact details of the GQHS to entities other than educational institutions. GQBC amended its policies and the contact page on gqbc-online.com to state that the only way for individuals and companies outside the state of Sachsen-Anhalt to contact the school is through a spam-filtered email address. It is entirely true that the attacker failed his goal to knock down the development of a global school network (GQNET), and we can proudly say it was not the fate of the pilot project for International education to fail. The attacker will soon receive a message from our principal stating the school is no longer responsible for his falsified claims and "scam warnings" and he will have to immediately stop to write any faxes, emails, or call the school. GQNET which was planned within the last weeks is now ready to start. There will be three main departments the network consists of: an Internet Service provider (GQNET.Connect) connecting all users to the GQNET , the .GQNET domain management (GQ NIC), and the team re-deploying the internal GQHS network to serve educational resources to the global GQNET (GQNET next-gen school network). GQNET.Connect is hereby officially introduced as the first educational Internet Service Provider with multi-homed deployment which will soon go on with the work I began, making IP addresses available for educational purposes free of charge. And of course, GQNET.Connect is primarily based in Michigan), therefore subject to be served by ARIN with IP addresses. I hope we can soon find a way to get the important IP's without long discussions caused by commercial companies trying to reserve IP addresses for their own prosper. The Web is an exponentially growing knowledge library and not the stock market. For those of you who want to benefit from a more inclusive name space the Public-Root, root of the Internet2 and our Top Level Domain sponsor, provides, go on http://inaic.com to receive further information on how to upgrade your desktop configurations and server hint files. Users of the Public-Root have instant access to most GQNET resources. Further, the Public-Root has master servers on all over the world and is therefore more reliable than the commercial legacy root, which is mainly deployed on the East and West coast of the US. Sincerely yours, Christopher Mettin Student Network Administrator GQBC _______________________________________________ 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 embedded message was scrubbed... From: "Christopher Mettin" Subject: RE: Notice of Appeal to the ARIN AUP Committee with respect to Gymnasium Querfurt and removal of Christopher Mettin Re: [arin-ppml] Official Spin-Off of GQBC and GQNET from the Gymnasium Querfurt High School to enhance education Date: Thu, 14 Jan 2010 16:03:05 +0100 Size: 42679 URL: From marty at akamai.com Fri Jan 15 13:18:28 2010 From: marty at akamai.com (Martin Hannigan) Date: Fri, 15 Jan 2010 13:18:28 -0500 Subject: [arin-ppml] Global policy development process [was: Re: NRPM2010.1 ? New Policies Implemented] In-Reply-To: <20100115165600.GA98382@ussenterprise.ufp.org> References: <20100115165600.GA98382@ussenterprise.ufp.org> Message-ID: On Jan 15, 2010, at 11:56 AM, Leo Bicknell wrote: > In a message written on Fri, Jan 15, 2010 at 08:43:13AM -0800, Lee > Howard wrote: > > What do you think the process for global policy development SHOULD > be? > > I have said before: > > ARIN should have a process similar to, but separate from the PDP > for "speaking". That is, we should be able to pass a resolution > like: > > "ARIN requests IANA to assign ASN's according to the following > criteria....." > > It makes no sense for such a thing to be put in our PDP, as there > is nothing for ARIN to do. It makes no sense to use the PDP process, > because each step (e.g. staff impact) is predicated on ARIN staff > doing something. It also makes no sense to list these things in > the PDP. For instance, we pass it and the other 4 RIR's do not, > it does not become IANA policy, but it is stuck in our PDP until > we go remove it. So we publish it on the web as if it is policy, > confusing everyone. > > Once all 5 RIR's make a formal request like the example above, IANA > could say: > > "All 5 RIR's have requested ASN's be assigned by the following > critera...." > > "As a result, the criteria above has been added to IANA policy > ABC.123, and will be implemented by IANA on Jan 1 ABCD." > > So it's pretty much exactly the same structure, but we stop calling > a request to IANA an ARIN policy, because, well, it isn't, and it > confuses everyone. > Might even be simpler. Initially, I always felt that the goal of "global policy" was not to regulate RIR's globally or for one RIR to try and impose it's wishes upon others, but to regulate ICANN and the actions that it performs for the addressing community. If you examine previous policies, they typically directed ICANN to perform a service in a specific way that had reached consensus amongst RIR's. This policy is an attempt to regulate the action of individual RIR's. I'm not surprised that the policy does not work for this. > > I can think of no more damning condemnation of the current process > than the fact that Mr Hannigan is asking the question, someone who > is currently on the ICANN ASO AC. If someone who is the next step > in the process can't understand what in the heck we're doing then > there's no way for the average Joe to keep track. > Others are welcome to [try and] come to different conclusions. http://aso.icann.org/documents/memorandum-of-understanding/ Best, -M< http://aso.icann.org/documents/memorandum-of-understanding/ From mcr at sandelman.ca Fri Jan 15 14:54:38 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 15 Jan 2010 14:54:38 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <4B4FA35F.9070804@arin.net> References: <4B4FA35F.9070804@arin.net> Message-ID: <30072.1263585278@marajade.sandelman.ca> >>>>> "Member" == Member Services writes: Member> Rationale: Member> This proposal provides a complete rework of the IPv6 Member> end-user assignment criteria, removing the dependency on Member> IPv4 policy, while maintaining many of the basic concepts Member> contained in the current policies. The order of the So why does it grandfather IPv4 users, and maintain the notion that everyone should use RFC1918/"10-net" addressing, which in IPv6 appears to be ULA. The clauses: a. Having a previously justified IPv4 end-users assignment from ARIN or one of its predecessor registries, or; make no sense. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Fri Jan 15 14:56:52 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 15 Jan 2010 14:56:52 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <4B4FA35F.9070804@arin.net> References: <4B4FA35F.9070804@arin.net> Message-ID: <30233.1263585412@marajade.sandelman.ca> >>>>> "Member" == Member Services writes: Member> 6.5.8.4 Criteria for initial assignment to Community Member> Networks Member> Organizations may justify an initial assignment for Member> operating a Community Network only for the purpose of Member> providing free or low-cost internet connectivity to the Member> residents of their local service area. Member> By documenting the service area they intend to serve, Member> certifying that the community network staff is 100% Member> volunteers, and otherwise meeting the definition of a Member> Community Network. Why does it matter how the staff is paid? We argued a lot about this before. Did we wind up with a definition? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Fri Jan 15 15:03:04 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jan 2010 12:03:04 -0800 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <30072.1263585278@marajade.sandelman.ca> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> Message-ID: On Jan 15, 2010, at 11:54 AM, Michael Richardson wrote: > >>>>>> "Member" == Member Services writes: > Member> Rationale: > > Member> This proposal provides a complete rework of the IPv6 > Member> end-user assignment criteria, removing the dependency on > Member> IPv4 policy, while maintaining many of the basic concepts > Member> contained in the current policies. The order of the > > So why does it grandfather IPv4 users, and maintain the notion that > everyone should use RFC1918/"10-net" addressing, which in IPv6 appears > to be ULA. > > The clauses: > a. Having a previously justified IPv4 end-users assignment from ARIN or > one of its predecessor registries, or; > > make no sense. > This is necessary to assure that those with IPv4 addresses are not prevented from obtaining IPv6 resources. Otherwise, policy may serve as a further barrier to IPv6 adoption by existing IPv4 users. Owen From tedm at ipinc.net Fri Jan 15 15:57:36 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 15 Jan 2010 12:57:36 -0800 Subject: [arin-ppml] =?iso-8859-1?q?Global_policy_development_process_=5Bw?= =?iso-8859-1?q?as=3A_Re=3A__NRPM_2010=2E1_=AD_New_Policies_Implemented=5D?= In-Reply-To: <247103.78548.qm@web63307.mail.re1.yahoo.com> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> <4B4F52FF.6010805@ipinc.net> <247103.78548.qm@web63307.mail.re1.yahoo.com> Message-ID: <4B50D6C0.8080205@ipinc.net> Lee Howard wrote: > >> Lee's statement was >> >> "...status of global policy PROPOSALS within the ARIN region..." >> >> The strong implication there is that these proposals are still proposals >> at this time. >> >> But I suspect Lee's hedging a bit himself, right now. I would!!! :-) > > Me, hedge? Never! > Well, hardly ever. ;-) > > I don't know if the process is wrong, but since people are debating about > what it actually IS, I think it's unclear. > > What do you think the process for global policy development SHOULD be? > I think that ICANN/IANA should effectively duplicate what we have for global policies - a mailing list with all interested parties, etc. My $0.02 here is that IANA has managed to "get away" without having to face anything the least bit controversial simply because there's been a plentiful supply of IPv4 addresses. IANA was born in an era where there were always more IPv4 addresses so all they had to do was limit themselves to only overseeing IP addressing policy - and since the only thing people would really ever complain about was "not having" an IPv4 address - they could always avoid controversy and "shut the complainers up" by handing them a block of numbers. The entire IPv6 thrust was an echo of this mentality. In other words, create so effing many globally unique IPv6 addresses that NOBODY could EVER complain again - and even the flimsiest, most ridiculously justified excuses for untold gobs of IPv6 addresses could be ignored with a pat on the head and "here, you want 26 bazillion IPv6 addresses, have them, we won't even notice" Pushing the global policy development responsibility on to the RIR's is yet another echo of this - it's the idea that we (IANA) don't want to get our hands dirty in the rough-and-tumble political world of hammering out policy, so we will make the RIR's do our dirty work while we remain in the ivory tower. The problem here is what we are running up against is the (understandably) strong desire of the public (represented by all of our customers) to not shift away from IPv4. People (and it's not just limited to customers, it includes a great many networks who have not got any IPv6 running on them at all) have a "chicken" mentality on this issue - they won't ABANDON IPv4 until "the other guy" does - and "the other guy" won't abandon IPv4 until the first guy does. Both players of this game could be FULLY DEPLOYED with IPv6 and they would STILL be playing it!!! Naturally, this silliness isn't doing anything to abate the hunger for more IPv4 and so the IPv4 train is still going 150Mph straight into the wall, here. So, we are starting to see more and more of a demand for the RIR's to ferret out unused IPv4, or retrieve it from networks who aren't using it, or whatever. The RIRs are stuck in the middle here, with multiple parties all pulling at them. I predict that we are only really seeing the beginnings of this problem right now. Imagine 5 years after IANA-runout-of-IPv4 if RIPE is being heavily pressed for more IPv4 by deep-pocket corporations in their area of responsibility - and those corps. want to know why ARIN has 70% of assigned IPv4 and RIPE only has 20%, and this is unfair, and who do we bribe to fix it? IANA is going to be forced to be drawn in to mediate between the RIR's because the RIR's are going to be forced by the ISP's to fight for IPv4 scraps, and the ISP's will be doing this because their customers with the dollars will be paying them to do it. And - not just corporations, governments will be involved in this as well. What if France Telecom goes to the French government and insists that IPv4 hoarding in a post-IPv4 world is putting France at a competitive disadvantage on the global market? Do you think the French government will do nothing? No, they will go to RIPE and bitch to them, and RIPE will pass the buck and say it's not our fault, IANA is out of addresses. Then IANA will say hey, it's not our fault, the IPv4 address hog is ARIN, since they have the bulk of IPv4 assignments. Then the French government will say to IANA well you are ARIN's boss so take some of those allocations back from them. It does not bode well for a "hands off" mentality at IANA, is my $0.02 Ted From mcr at sandelman.ca Fri Jan 15 15:58:48 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 15 Jan 2010 15:58:48 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> Message-ID: <7517.1263589128@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: Member> Rationale: Member> This proposal provides a complete rework of the IPv6 Member> end-user assignment criteria, removing the dependency on Member> IPv4 policy, while maintaining many of the basic concepts Member> contained in the current policies. The order of the >> So why does it grandfather IPv4 users, and maintain the notion >> that everyone should use RFC1918/"10-net" addressing, which in >> IPv6 appears to be ULA. >> >> The clauses: a. Having a previously justified IPv4 end-users >> assignment from ARIN or one of its predecessor registries, or; >> >> make no sense. Owen> This is necessary to assure that those with IPv4 addresses are Owen> not prevented from obtaining IPv6 resources. Otherwise, Owen> policy may serve as a further barrier to IPv6 adoption by Owen> existing IPv4 users. Give me a real example. Current IPv4 policy encourages people to use RFC1918 addresses, and prevents those people from easily getting more useful unconnected IPv6. Your proposal does not seem to make it any easier for an enterprise to get a unique, unconnected /48, and therefore is preventing adopting of IPv6. (Sorry, ULA is no better than RFC1918, which means that there is no business case for moving to IPv6) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From terry.l.davis at boeing.com Fri Jan 15 16:33:16 2010 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 15 Jan 2010 13:33:16 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> I've been a big supporter of IPv6 for a decade now since I was in the FTTH business for awhile in 2000-2001. Industry has spent an enormous amount in developing it both in network and in the end systems. And I still feel it has huge potentials to allow us to improve the Internet. But yet even with the globe rushing headlong toward the end of IPv4 space, probably within 24 months, v6 is still barely crawling forward in deployments. It's not going into greenfields, startups, etc. It is still hard to find native v6 transport. I don't know of a v6 network anywhere approaching even approaching 100,000 systems (I hope I'm wrong!) on the globe. Yea I finally realized in doing my Master's paper a couple years back that we had really screwed up by not defining a native way to allow v4 to v6 communications. As is, you basically have to open every v4 app and re-write it to utilize v6; none of the existing transition technologies cover all the v4 to v6 communications scenarios. With this much installed v4, the cost of opening every existing app to change it to be dual-stacked is staggering. We can argue endlessly about the risks of opening v6 address allocation policy but in the end, if we cannot get the Internet developers to utilize it, all the investment of the IT and comm vendors will be lost. One of the alternatives to IPv6 will win (geo routing, 5th octet, something-out-of-the-blue, etc) and all that investment in IPv6 and its potential enhancements to the Internet will be lost to us. If I represented an IT or comm vendor right now, I'd be doing everything I could to get IPv6 used, including completely re-thinking or totally opening up the allocation policies and reducing the costs to near zero, just to protect my investments. Take care Terry PS: Yes believe me I have heard all the arguments why we can't do that completely re-think allocations. But I've come to believe that unless we can find a way move v6 implementations rapidly forward, innovation will take the Internet in a completely new direction. From bicknell at ufp.org Fri Jan 15 17:10:32 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Jan 2010 14:10:32 -0800 Subject: [arin-ppml] Global policy development process [was: Re: NRPM 2010.1 ? New Policies Implemented] In-Reply-To: <4B50D6C0.8080205@ipinc.net> References: <4B4E5188.7020701@ipinc.net> <95A6A8D5-765C-4657-B2FD-6F2320D5EEC1@akamai.com> <4B4F4CB3.7060507@ipinc.net> <4B4F52FF.6010805@ipinc.net> <247103.78548.qm@web63307.mail.re1.yahoo.com> <4B50D6C0.8080205@ipinc.net> Message-ID: <20100115221032.GB24711@ussenterprise.ufp.org> In a message written on Fri, Jan 15, 2010 at 12:57:36PM -0800, Ted Mittelstaedt wrote: > I think that ICANN/IANA should effectively duplicate what we have for > global policies - a mailing list with all interested parties, etc. Your description encompases several different aspects of how ICANN/IANA works, but let me dive into a particularly interesting case. Let's say 4 of the 5 RIR's agree strongly for some reason that IP's should only be issued on Tuesdays and Thursdays (as a straw man). Today there is absolutely no way to enforce that on the 5th RIR. It takes all 5 to agree to any change in the IANA policy, so if you wrote the "stick policy" of: "IANA will only provide IP's to RIR's who issue them on Tuesday's and Thursday's." You could never get it passed. This is both the simplest, and extreme case of what we have now. Think of a 5 clause global policy where ARIN wants to change clause 1, LANIC clause 2, APNIC clause 3, and so on. You end up with deadlock. There are, at a high level, two ways to address this: 1) Lower the threshold at the IANA level. This is simple. Change it so the NRO NC can certify a global policy once 3 or 4 of the 5 RIR's sign off on it. 2) Create a PDP at the IANA level. This would be "top down" policy development, as opposed to the current RIR "bottom up" policy development. Some representatives of the RIR's (think ASO AC members, or sending part of the staff, or sending the AC) would particiapte in a IANA PDP with some process to come up with an idea, evaluate it, and pass it. The second idea seems more complete and fair, but it is also much more heavyweight. It also creates a very interesting question for each of the RIR's about who represents them. There is also the problem that it turns the "bottom up" process on its head, which some may feel is a good thing, while others may not like. > The problem here is what we are running up against is the > (understandably) strong desire of the public (represented by > all of our customers) to not shift away from IPv4. People (and it's > not just limited to customers, it includes a great many networks > who have not got any IPv6 running on them at all) have a "chicken" > mentality on this issue - they won't ABANDON IPv4 until "the other > guy" does - and "the other guy" won't abandon IPv4 until the first > guy does. Both players of this game could be FULLY DEPLOYED with > IPv6 and they would STILL be playing it!!! While that may be a principal problem, that is not the only problem. Even if folks were willing to move to IPv6, we still had to create a way to reuse IPv4 through IANA (most likely). We still had to figure out how we were going to handle 16 bit ASN exhaustion, and so on. Now, with all that said (as it would appear I'm in full support of an actual global policy process) there are more practical problems. ICANN operates under MoU's with several entities. There's a lot invested in the "bottom up" process. ICANN is not set up (staff, resources) to host a real global PDP at this time. It's unclear what carrots and sticks could be used to get everyone on board with such a system. I strongly prefer evolutionary change over revolutionary change. I also prefer when that evolutionary change is moving towards a target in the distance. The central tennant of Ted's post is that the world today is not the world when these things were set up. We shouldn't throw the baby out with the bath water, but we might want to take notice that the baby is now a teenager. I leave with this: I support ARIN {staff,board,AC} looking into how the global PDP could be changed or improved, and making recommendations. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From tedm at ipinc.net Fri Jan 15 17:23:21 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 15 Jan 2010 14:23:21 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4B50EAD9.2010506@ipinc.net> Davis, Terry L wrote: > I've been a big supporter of IPv6 for a decade now since I was in the > FTTH business for awhile in 2000-2001. Industry has spent an > enormous amount in developing it both in network and in the end > systems. And I still feel it has huge potentials to allow us to > improve the Internet. > > But yet even with the globe rushing headlong toward the end of IPv4 > space, probably within 24 months, v6 is still barely crawling forward > in deployments. It's not going into greenfields, startups, etc. It > is still hard to find native v6 transport. I don't know of a v6 > network anywhere approaching even approaching 100,000 systems (I hope > I'm wrong!) on the globe. > > Yea I finally realized in doing my Master's paper a couple years back > that we had really screwed up by not defining a native way to allow > v4 to v6 communications. Not true. I used to run OS/2. Remember that? OS/2 Warp? Well let me tell you something about transitions. IBM knocked themselves out adding seamless windows support into OS/2 Warp. They really wanted to be able to say that Warp ran Windows better than Windows does. And they succeeded so well that their software partners - like DeScribe - who for years ONLY produced OS/2 versions of software, ended up going out of business because all the Warp users out there simply used their legacy Windows applications under OS/2 and never bothered switching to OS/2 apps. Why would they, when Windows apps worked so well under OS/2? Some things call for backwards-compatibility. Some things instead call for making it very painful for the customers so that they are forced to spend money to upgrade - because their upgrades are for the greater good of the community. The customers who refuse to upgrade are then cast-aside, they are winnowed out. It may seem unfair - but to this day there's still people out there who have refused to give up their Commodore 64's and buy PCs. That is just a fact of life with change. Some people refuse to accept it and will just continue on with what they know - until they are among a small minority, and then they die of old age. Look at the HDTV business. We all know the US Government gave everyone free converter boxes to get their crappy old TV sets to work on HD. But, the US Government DID NOT pay for anyone to get a brand new HDTV UHF antenna, even though millions of people were running set-top rabbit ears, or VHF antennas on the top of their roofs. And those millions of people were basically told you go spend $35 on a new Channel Master UHF antenna and find some handyman to climb around on the top of your roof and install it. We aren't going to make the signal backwards compatible to your old VHF antenna because we know damn well you wouldn't lift a finger to replace your antenna. We know that customers aren't going to spend money unless they have to. Sometimes you just gotta be a hard-ass and don't give them a choice to NOT spend the money. This is one of those times. > As is, you basically have to open every v4 > app and re-write it to utilize v6; correct > none of the existing transition > technologies cover all the v4 to v6 communications scenarios. With > this much installed v4, the cost of opening every existing app to > change it to be dual-stacked is staggering. > That doesn't matter. All of those apps your talking about are going to be obsolete in 20 years and replaced by new versions so that staggering cost is going to be spent either way. > We can argue endlessly about the risks of opening v6 address > allocation policy but in the end, if we cannot get the Internet > developers to utilize it, all the investment of the IT and comm > vendors will be lost. One of the alternatives to IPv6 will win (geo > routing, 5th octet, something-out-of-the-blue, etc) and all that > investment in IPv6 and its potential enhancements to the Internet > will be lost to us. > If you really think that an alternative to IPv6 has a chance then where are all those startup software companies writing to one of those alternative standards? Why isn't Microsoft pushing one of those? out-of-the-blue laboratory curiosities implemented on Linux just aren't going to make any difference. The future is IPv6 and all the big players are betting on it, and the economic situation in the world right now is not such that anyone is going to put any real money into an alternative. The question isn't whether it's going to be IPv6 vs some kludgy IPv4 alternative. The question is going to be how far can we stretch the IPv4 that we have. It's been observed before on this list that most large networks have very "loose" allocations. For example the standard customer static IPv4 allocation is a /29 and a /30 on a point-to-point link to that customer. In reality it could be a /30 and unnumbered on the point-to-point link since it's almost a given that all of the customers getting /29's are only using a single number. And if you want to force the end user to use a /32 you can run PPP right to their router. I think most established ISP's are aware of this and figure they can self-generate IPv4 for 3-5 years post-runout. Their feeling is why should I kill myself trying to kick my peers asses to get them running IPv6 natively, when I can do nothing and allow all the deep-pocket startup ISP's out there who are flush with VC funding and have no IPv4 stored up, to beat my peers for me. Then once my peers are IPv6 native, I'll just switch it on and be gold. It kind of sucks for the new guy on the block, but that is also a normal characteristic of established markets. Ted From sbarber at theplanet.com Fri Jan 15 18:44:22 2010 From: sbarber at theplanet.com (Barber, Stan) Date: Fri, 15 Jan 2010 17:44:22 -0600 Subject: [arin-ppml] V6 address allocation policy References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <8FF49FA5103C8D4DB1933ECE41EB477F04823521@HOUEXCH01.PLANET.LOCAL> Terry, NTT has a large v6 deployment to the home in Japan called Hakari-TV. This is a walled-garden deployment for VOD (and other related features) to the home. Cody Christman (from NTT America) discussed this at the TXv6TF conference in November. In his talk, he presented a chart indicating that they had 11 million subscribers on this deployment of IPv6. See http://www.txv6tf.org/wp-content/uploads/2009/11/Texas-IPv6TF-November-2009-Christman.pdf for the presentation. Stan Barber, Director TXv6TF -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Davis, Terry L Sent: Fri 1/15/2010 3:33 PM To: arin-ppml at arin.net Subject: [arin-ppml] V6 address allocation policy I've been a big supporter of IPv6 for a decade now since I was in the FTTH business for awhile in 2000-2001. Industry has spent an enormous amount in developing it both in network and in the end systems. And I still feel it has huge potentials to allow us to improve the Internet. But yet even with the globe rushing headlong toward the end of IPv4 space, probably within 24 months, v6 is still barely crawling forward in deployments. It's not going into greenfields, startups, etc. It is still hard to find native v6 transport. I don't know of a v6 network anywhere approaching even approaching 100,000 systems (I hope I'm wrong!) on the globe. Yea I finally realized in doing my Master's paper a couple years back that we had really screwed up by not defining a native way to allow v4 to v6 communications. As is, you basically have to open every v4 app and re-write it to utilize v6; none of the existing transition technologies cover all the v4 to v6 communications scenarios. With this much installed v4, the cost of opening every existing app to change it to be dual-stacked is staggering. We can argue endlessly about the risks of opening v6 address allocation policy but in the end, if we cannot get the Internet developers to utilize it, all the investment of the IT and comm vendors will be lost. One of the alternatives to IPv6 will win (geo routing, 5th octet, something-out-of-the-blue, etc) and all that investment in IPv6 and its potential enhancements to the Internet will be lost to us. If I represented an IT or comm vendor right now, I'd be doing everything I could to get IPv6 used, including completely re-thinking or totally opening up the allocation policies and reducing the costs to near zero, just to protect my investments. Take care Terry PS: Yes believe me I have heard all the arguments why we can't do that completely re-think allocations. But I've come to believe that unless we can find a way move v6 implementations rapidly forward, innovation will take the Internet in a completely new direction. _______________________________________________ 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 marty at akamai.com Fri Jan 15 20:56:00 2010 From: marty at akamai.com (Martin Hannigan) Date: Fri, 15 Jan 2010 20:56:00 -0500 Subject: [arin-ppml] Global policy development process [was: Re: NRPM2010.1 ? New Policies Implemented] In-Reply-To: <20100115221032.GB24711@ussenterprise.ufp.org> References: <20100115221032.GB24711@ussenterprise.ufp.org> Message-ID: <8495246E-7292-43E0-89AE-8BEA9E52779F@akamai.com> On Jan 15, 2010, at 5:10 PM, Leo Bicknell wrote: > In a message written on Fri, Jan 15, 2010 at 12:57:36PM -0800, Ted > Mittelstaedt wrote: > > I think that ICANN/IANA should effectively duplicate what we have > for > > global policies - a mailing list with all interested parties, etc. > > Ted: Well, it's called ARIN PPML and it has worked for several years. [ clip ] > I leave with this: I support ARIN {staff,board,AC} looking into how > the global PDP could be changed or improved, and making > recommendations. > > Leo: I strongly support the AC coming up with regional policy that is regional. :) From farmer at umn.edu Sat Jan 16 00:26:32 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 15 Jan 2010 23:26:32 -0600 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <30233.1263585412@marajade.sandelman.ca> References: <4B4FA35F.9070804@arin.net> <30233.1263585412@marajade.sandelman.ca> Message-ID: <4B514E08.30209@umn.edu> Michael Richardson wrote: >>>>>> "Member" == Member Services writes: > Member> 6.5.8.4 Criteria for initial assignment to Community > Member> Networks > > Member> Organizations may justify an initial assignment for > Member> operating a Community Network only for the purpose of > Member> providing free or low-cost internet connectivity to the > Member> residents of their local service area. > > Member> By documenting the service area they intend to serve, > Member> certifying that the community network staff is 100% > Member> volunteers, and otherwise meeting the definition of a > Member> Community Network. > > Why does it matter how the staff is paid? > We argued a lot about this before. Did we wind up with a definition? > 2008-3 Community Networks was just added to the NRPM, two days ago, and that requirement is in the definition. 2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers. I don't necessarily disagree with your comment, but that was the consensus we came up with and I really really don't want to revisit that for a policy that just got put into the NRPM two days ago. I was only trying to remove some of the duplication of text in how it was implemented, but making it another type of initial assignment criteria. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Sat Jan 16 02:01:56 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jan 2010 23:01:56 -0800 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <7517.1263589128@marajade.sandelman.ca> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <7517.1263589128@marajade.sandelman.ca> Message-ID: <05F0230C-CB09-47FE-BACC-14E408ABF7FD@delong.com> On Jan 15, 2010, at 12:58 PM, Michael Richardson wrote: > >>>>>> "Owen" == Owen DeLong writes: > Member> Rationale: > > Member> This proposal provides a complete rework of the IPv6 > Member> end-user assignment criteria, removing the dependency on > Member> IPv4 policy, while maintaining many of the basic concepts > Member> contained in the current policies. The order of the > >>> So why does it grandfather IPv4 users, and maintain the notion >>> that everyone should use RFC1918/"10-net" addressing, which in >>> IPv6 appears to be ULA. >>> >>> The clauses: a. Having a previously justified IPv4 end-users >>> assignment from ARIN or one of its predecessor registries, or; >>> >>> make no sense. > > Owen> This is necessary to assure that those with IPv4 addresses are > Owen> not prevented from obtaining IPv6 resources. Otherwise, > Owen> policy may serve as a further barrier to IPv6 adoption by > Owen> existing IPv4 users. > > Give me a real example. > > Current IPv4 policy encourages people to use RFC1918 addresses, > and prevents those people from easily getting more useful unconnected > IPv6. > If you have ROUTABLE (believe it or not, lots of people like being connected to the internet instead of connected to something sort of connected to the internet) IPv4 addresses, and, you want to get routable IPv6 addresses, that is supported in current policy and preserved in this rewrite. > Your proposal does not seem to make it any easier for an enterprise to > get a unique, unconnected /48, and therefore is preventing adopting of IPv6. > (Sorry, ULA is no better than RFC1918, which means that there is no > business case for moving to IPv6) > Sure it does... An unconnected /48 is a /48 of routable space that you don't route on the internet. Additionally, ULA is quite a bit better than RFC-1918 in that it grants you at least statistical uniqueness, and, if you choose to participate in the SIXXS ULA registry (which I think is a bad idea, but, I can't deny it exists, so, for people that think it's a good idea, there you go), you can get registry-like uniqueness in ULA. Finally, it is not the job of policy to create or expand the business case for IPv6. It is the job of policy to avoid hinderance to legitimate usage of IPv6 to the extent possible without otherwise damaging the stability of the internet. Making the business case is up to the employees of a given business and other efforts such as some of ARIN's outreach activities. Owen From notdoctorx at yahoo.ca Sat Jan 16 09:38:05 2010 From: notdoctorx at yahoo.ca (Not Doctor X) Date: Sat, 16 Jan 2010 06:38:05 -0800 (PST) Subject: [arin-ppml] Appology from the Gymnasium Querfurt regarding Christopher Mettin Message-ID: <544803.25134.qm@web113912.mail.gq1.yahoo.com> This is Not Doctor X posting to the ARIN-PPML. This is Joe Baptista posting under another email address because my regular email address has been blocked or censored from posting to the ARIN-PPML list. I am however receiving email from the list. I'm sure this is an oversight which will be corrected soon. I believe that Christopher Mettin is also being blocked from posting. In any case I am pleased to provide notice to the community that I received a letter from Dr. Hans Daumer the principle of the Gymnasium Querfurt High School. Dr. Daumer has apologized to me and I accept Dr. Daumer's apology. A copy of the apology is indexed at the following URL: http://bit.ly/7It7ej It is clear from a reading of this correspondence from Dr. Daumer that Christopher Mettin has deceived and mislead the membership. Mr. Mettin has no authority to represent the school nor did he ever have that authority. The claims made by Mettin here connecting his school the Gymnasium Querfurt to any of his projects for higher education are false. We can safely dismiss Mr. Mettin's claims as false bogus statements made in support of a scam to get IP numbers. I will now make my submissions to the ARIN AUP Committee under separate cover. kindest regards joe baptista __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sat Jan 16 10:55:30 2010 From: jcurran at arin.net (John Curran) Date: Sat, 16 Jan 2010 10:55:30 -0500 Subject: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review Message-ID: Joe - You are correct; your email postings to PPML are being held pending review by the AUP Committee because of complaints of violation. Please do not circumvent this by posting under alternative fictitious names, as this is also specifically prohibited by the AUP. You are welcome to send any materials for the AUP Committee to consider to myself > or to Scott Bradner > (who is the chair of the 2010 AUP Committee). /John John Curran President and CEO ARIN From: Not Doctor X > Date: January 16, 2010 9:38:05 AM EST To: arin-ppml at arin.net Subject: [arin-ppml] Appology from the Gymnasium Querfurt regarding Christopher Mettin This is Not Doctor X posting to the ARIN-PPML. This is Joe Baptista posting under another email address because my regular email address has been blocked or censored from posting to the ARIN-PPML list. I am however receiving email from the list. I'm sure this is an oversight which will be corrected soon. I believe that Christopher Mettin is also being blocked from posting. In any case I am pleased to provide notice to the community that I received a letter from Dr. Hans Daumer the principle of the Gymnasium Querfurt High School. Dr. Daumer has apologized to me and I accept Dr. Daumer's apology. A copy of the apology is indexed at the following URL: http://bit.ly/7It7ej It is clear from a reading of this correspondence from Dr. Daumer that Christopher Mettin has deceived and mislead the membership. Mr. Mettin has no authority to represent the school nor did he ever have that authority. The claims made by Mettin here connecting his school the Gymnasium Querfurt to any of his projects for higher education are false. We can safely dismiss Mr. Mettin's claims as false bogus statements made in support of a scam to get IP numbers. I will now make my submissions to the ARIN AUP Committee under separate cover. kindest regards joe baptista -------------- next part -------------- An HTML attachment was scrubbed... URL: From notdoctorx at yahoo.ca Sat Jan 16 12:15:09 2010 From: notdoctorx at yahoo.ca (Not Doctor X) Date: Sat, 16 Jan 2010 09:15:09 -0800 (PST) Subject: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review In-Reply-To: References: Message-ID: <921874.2184.qm@web113912.mail.gq1.yahoo.com> Dear Mr. Curran: Thank you for the clarification. However I have received no notice from the AUP committee and it is my understanding my posting privileges can only be suspended once notice is made. I would also like an opportunity to respond to the complaint and would request that any complaints be provided to me. Next I did not post using a fictitious name. I made very clear I was the one posting. There was no attempt to defraud or deceive nor have I in any way violated the AUP. You have also suspended my posting privileges without notice and this suspension causes me the injured party in this further damage. This time by ARIN itself. regards joe baptista ________________________________ From: John Curran To: Joe Baptista ; Not Doctor X Cc: arin ppml Sent: Sat, January 16, 2010 10:55:30 AM Subject: Mail postings from Joe Baptista held pending AUP Committee review Joe - You are correct; your email postings to PPML are being held pending review by the AUP Committee because of complaints of violation. Please do not circumvent this by posting under alternative fictitious names, as this is also specifically prohibited by the AUP. You are welcome to send any materials for the AUP Committee to consider to myself or to Scott Bradner (who is the chair of the 2010 AUP Committee). /John John Curran President and CEO ARIN From: Not Doctor X > >Date: January 16, 2010 9:38:05 AM EST > >To: arin-ppml at arin.net > >Subject: [arin-ppml] Appology from the Gymnasium Querfurt regarding Christopher Mettin > > >This is Not Doctor X posting to the ARIN-PPML. This is Joe Baptista posting under another email address because my regular email address has been blocked or censored from posting to the ARIN-PPML list. I am however receiving email from the list. I'm sure this is an oversight which will be corrected soon. I believe that Christopher Mettin is also being blocked from posting. > >In any case I am pleased to provide notice to the community that I received a letter from Dr. Hans Daumer the principle of the Gymnasium Querfurt High School. Dr. Daumer has apologized to me and I accept Dr. Daumer's apology. A copy of the apology is indexed at the following URL: > >http://bit.ly/7It7ej > >It is clear from a reading of this correspondence from Dr. Daumer that Christopher Mettin has deceived and mislead the membership. Mr. Mettin has no authority to represent the school nor did he ever have that authority. The claims made by Mettin here connecting his school the Gymnasium Querfurt to any of his projects for higher education are false. We can safely dismiss Mr. Mettin's claims as false bogus statements made in support of a scam to get IP numbers. > >I will now make my submissions to the ARIN AUP Committee under separate cover. > >kindest regards >joe baptista > > __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sat Jan 16 12:43:26 2010 From: jcurran at arin.net (John Curran) Date: Sat, 16 Jan 2010 12:43:26 -0500 Subject: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review In-Reply-To: <921874.2184.qm@web113912.mail.gq1.yahoo.com> References: <921874.2184.qm@web113912.mail.gq1.yahoo.com> Message-ID: <5F4D6170-5773-4A35-A9E8-1EC887050042@arin.net> Joe - First, you are mistaken, in that actions enforcing the AUP may be taken at any time and no notice is required before or after. At all times, ARIN reserves the right to maintain order and decorum on the mailing lists it manages, and your messages were being held awaiting review of the complaints. Second, the use of "Not Doctor X" is likely to be considered a fictitious name by many, but I'll leave that to the AUP committee to judge. You've been provided contact information for AUP Committee; free free to contact them, but in any case immediately cease posting to ARIN PPML (under any and all aliases) until informed otherwise. Thank you, /John John Curran President and CEO ARIN On Jan 16, 2010, at 12:15 PM, Not Doctor X wrote: Dear Mr. Curran: Thank you for the clarification. However I have received no notice from the AUP committee and it is my understanding my posting privileges can only be suspended once notice is made. I would also like an opportunity to respond to the complaint and would request that any complaints be provided to me. Next I did not post using a fictitious name. I made very clear I was the one posting. There was no attempt to defraud or deceive nor have I in any way violated the AUP. You have also suspended my posting privileges without notice and this suspension causes me the injured party in this further damage. This time by ARIN itself. regards joe baptista -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Sat Jan 16 14:38:30 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 16 Jan 2010 11:38:30 -0800 Subject: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review In-Reply-To: <5F4D6170-5773-4A35-A9E8-1EC887050042@arin.net> References: <921874.2184.qm@web113912.mail.gq1.yahoo.com> <5F4D6170-5773-4A35-A9E8-1EC887050042@arin.net> Message-ID: <4B5215B6.3050404@matthew.at> This thread is as bad as the thread that's being blocked. Can't we have the AUP folks block the thread *and* discussion about the thread? And yes, starting with this posting would be fine. Matthew Kaufman From mcr at sandelman.ca Sat Jan 16 19:28:52 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 16 Jan 2010 19:28:52 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <32154.1263688132@marajade.sandelman.ca> >>>>> "Terry" == Terry L Davis writes: Terry> But yet even with the globe rushing headlong toward the end Terry> of IPv4 space, probably within 24 months, v6 is still barely Terry> crawling forward in deployments. It's not going into Terry> greenfields, startups, etc. If techies need to get their managers to approve a checque to ARIN, the manager tells them to use IPv4 + NAT. If the techies do not have to ask, then they will deploy IPv6 for internal use. (ULA buys you nothing compared to net-10) Terry> If I represented an IT or comm vendor right now, I'd be doing Terry> everything I could to get IPv6 used, including completely Terry> re-thinking or totally opening up the allocation policies and Terry> reducing the costs to near zero, just to protect my Terry> investments. +1 -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Sat Jan 16 19:31:46 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 16 Jan 2010 19:31:46 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <8FF49FA5103C8D4DB1933ECE41EB477F04823521@HOUEXCH01.PLANET.LOCAL> References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <8FF49FA5103C8D4DB1933ECE41EB477F04823521@HOUEXCH01.PLANET.LOCAL> Message-ID: <32402.1263688306@marajade.sandelman.ca> >>>>> "Stan" == Stan Barber writes: Stan> Terry, NTT has a large v6 deployment to the home in Japan Stan> called Hakari-TV. This is a walled-garden deployment for VOD Stan> (and other related features) to the home. By "walled garden", do you mean that the address space is not globally routed? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Sat Jan 16 19:44:19 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 16 Jan 2010 19:44:19 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <4B514E08.30209@umn.edu> References: <4B4FA35F.9070804@arin.net> <30233.1263585412@marajade.sandelman.ca> <4B514E08.30209@umn.edu> Message-ID: <776.1263689059@marajade.sandelman.ca> >>>>> "David" == David Farmer writes: Member> 6.5.8.4 Criteria for initial assignment to Community Member> Networks Organizations may justify an initial assignment for Member> operating a Community Network only for the purpose of Member> providing free or low-cost internet connectivity to the Member> residents of their local service area. By documenting the Member> service area they intend to serve, certifying that the Member> community network staff is 100% volunteers, and otherwise Member> meeting the definition of a Community Network. >> Why does it matter how the staff is paid? We argued a lot about >> this before. Did we wind up with a definition? David> 2008-3 Community Networks was just added to the NRPM, two David> days ago, and that requirement is in the definition. Good, I wasn't sure if it happened. David> 2.11. Community Network David> A community network is any network organized and operated by David> a volunteer group operating as or under the fiscal support of David> a nonprofit organization or university for the purpose of David> providing free or low-cost connectivity to the residents of David> their local service area. To be treated as a community David> network under ARIN policy, the applicant must certify to ARIN David> that the community network staff is 100% volunteers. If the definition is already there, then you do not need to repeat it. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Sat Jan 16 19:55:07 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 16 Jan 2010 16:55:07 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <32154.1263688132@marajade.sandelman.ca> References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> Message-ID: On Jan 16, 2010, at 4:28 PM, Michael Richardson wrote: > >>>>>> "Terry" == Terry L Davis writes: > Terry> But yet even with the globe rushing headlong toward the end > Terry> of IPv4 space, probably within 24 months, v6 is still barely > Terry> crawling forward in deployments. It's not going into > Terry> greenfields, startups, etc. > > If techies need to get their managers to approve a checque to ARIN, > the manager tells them to use IPv4 + NAT. If the techies do not have to > ask, then they will deploy IPv6 for internal use. > (ULA buys you nothing compared to net-10) > 1. ULA buys you a great deal more than RFC-1918. ULA is statistically, if not globally unique. 2. You can get IPv6 space from many sources other than writing a check to ARIN. For example, you can get a /48 with tunneled service from several tunnel brokers. 3. You can get native IPv6 service with address space from several ISPs. If you have IPv4 space from ARIN, then, there's a one-time check to ARIN to get IPv6 space. After that, you probably aren't paying any more going forward for IPv4+IPv6 than you were already paying for IPv4. Owen From mcr at sandelman.ca Sat Jan 16 20:27:36 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 16 Jan 2010 20:27:36 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> Message-ID: <4320.1263691656@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: Terry> But yet even with the globe rushing headlong toward the end Terry> of IPv4 space, probably within 24 months, v6 is still barely Terry> crawling forward in deployments. It's not going into Terry> greenfields, startups, etc. >> If techies need to get their managers to approve a checque to ARIN, >> the manager tells them to use IPv4 + NAT. If the techies do not have to >> ask, then they will deploy IPv6 for internal use. >> (ULA buys you nothing compared to net-10) Owen> 1. ULA buys you a great deal more than RFC-1918. ULA is Owen> statistically, Owen> if not globally unique. Tell me what it gets me. Tell me how, when two organizations merge, ULA saves them anything? Owen> 2. You can get IPv6 space from many sources other than Owen> writing a check to ARIN. For example, you can get a /48 with Owen> tunneled service from several tunnel brokers. Yes, that's what I currently advise people who need some address space. The tunnel brockers also give me reverse DNS and sometimes whois. Is that really what ARIN wants? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From farmer at umn.edu Sat Jan 16 21:13:55 2010 From: farmer at umn.edu (David Farmer) Date: Sat, 16 Jan 2010 20:13:55 -0600 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <776.1263689059@marajade.sandelman.ca> References: <4B4FA35F.9070804@arin.net> <30233.1263585412@marajade.sandelman.ca> <4B514E08.30209@umn.edu> <776.1263689059@marajade.sandelman.ca> Message-ID: <4B527263.7090406@umn.edu> Michael Richardson wrote: >>>>>> "David" == David Farmer writes: > Member> 6.5.8.4 Criteria for initial assignment to Community > Member> Networks Organizations may justify an initial assignment for > Member> operating a Community Network only for the purpose of > Member> providing free or low-cost internet connectivity to the > Member> residents of their local service area. By documenting the > Member> service area they intend to serve, certifying that the > Member> community network staff is 100% volunteers, and otherwise > Member> meeting the definition of a Community Network. > > >> Why does it matter how the staff is paid? We argued a lot about > >> this before. Did we wind up with a definition? > > David> 2008-3 Community Networks was just added to the NRPM, two > David> days ago, and that requirement is in the definition. > > Good, I wasn't sure if it happened. > > David> 2.11. Community Network > > David> A community network is any network organized and operated by > David> a volunteer group operating as or under the fiscal support of > David> a nonprofit organization or university for the purpose of > David> providing free or low-cost connectivity to the residents of > David> their local service area. To be treated as a community > David> network under ARIN policy, the applicant must certify to ARIN > David> that the community network staff is 100% volunteers. > > If the definition is already there, then you do not need to repeat it. Yes, I had quickly added that part to the proposal after realizing 2008-3 had finally been added to the NRPM and that part didn't go through the same amount of refinement as the rest of the proposal. I am thinking about replacing that part with the following text. ---- 6.5.8.4 Criteria for initial assignment to Community Networks Organizations may justify an initial assignment for operating a Community Network only for the purpose of providing free or low-cost Internet connectivity to the residents of their local service area. By documenting the service area they intend to serve and certifying that the network meets all the requirements of the definition of a Community Network from section 2.11. ---- Is that better? Should the current section 6.10 Micro Allocation be integrated into this section as separate criteria? Micro Allocation have little technical difference from assignments. Or, should we just leave them as a separate section. This one is on a bit of a fast-track to get it ready for the up coming Toronto meeting. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Sat Jan 16 21:26:59 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 16 Jan 2010 18:26:59 -0800 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <4B527263.7090406@umn.edu> References: <4B4FA35F.9070804@arin.net> <30233.1263585412@marajade.sandelman.ca> <4B514E08.30209@umn.edu> <776.1263689059@marajade.sandelman.ca> <4B527263.7090406@umn.edu> Message-ID: How about this: 6.5.8.4 Initial Assignments to Community Networks Organizations may receive an initial assignment for operating a Community Network after documenting that they meet the criteria specified in section 2.11. Owen On Jan 16, 2010, at 6:13 PM, David Farmer wrote: > Michael Richardson wrote: >>>>>>> "David" == David Farmer writes: >> Member> 6.5.8.4 Criteria for initial assignment to Community >> Member> Networks Organizations may justify an initial assignment for >> Member> operating a Community Network only for the purpose of >> Member> providing free or low-cost internet connectivity to the >> Member> residents of their local service area. By documenting the >> Member> service area they intend to serve, certifying that the >> Member> community network staff is 100% volunteers, and otherwise >> Member> meeting the definition of a Community Network. >> >> Why does it matter how the staff is paid? We argued a lot about >> >> this before. Did we wind up with a definition? >> David> 2008-3 Community Networks was just added to the NRPM, two >> David> days ago, and that requirement is in the definition. >> Good, I wasn't sure if it happened. >> David> 2.11. Community Network >> David> A community network is any network organized and operated by >> David> a volunteer group operating as or under the fiscal support of >> David> a nonprofit organization or university for the purpose of >> David> providing free or low-cost connectivity to the residents of >> David> their local service area. To be treated as a community >> David> network under ARIN policy, the applicant must certify to ARIN >> David> that the community network staff is 100% volunteers. >> If the definition is already there, then you do not need to repeat it. > > Yes, I had quickly added that part to the proposal after realizing 2008-3 had finally been added to the NRPM and that part didn't go through the same amount of refinement as the rest of the proposal. I am thinking about replacing that part with the following text. > > ---- > 6.5.8.4 Criteria for initial assignment to Community Networks > > Organizations may justify an initial assignment for operating a Community Network only for the purpose of providing free or low-cost Internet connectivity to the residents of their local service area. > > By documenting the service area they intend to serve and certifying that the network meets all the requirements of the definition of a Community Network from section 2.11. > ---- > > Is that better? > > Should the current section 6.10 Micro Allocation be integrated into this section as separate criteria? Micro Allocation have little technical difference from assignments. Or, should we just leave them as a separate section. > > This one is on a bit of a fast-track to get it ready for the up coming Toronto meeting. > > Thanks > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 notdoctorx at yahoo.ca Sun Jan 17 09:24:05 2010 From: notdoctorx at yahoo.ca (Not Doctor X) Date: Sun, 17 Jan 2010 06:24:05 -0800 (PST) Subject: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review In-Reply-To: <5F4D6170-5773-4A35-A9E8-1EC887050042@arin.net> References: <921874.2184.qm@web113912.mail.gq1.yahoo.com> <5F4D6170-5773-4A35-A9E8-1EC887050042@arin.net> Message-ID: <788174.73831.qm@web113919.mail.gq1.yahoo.com> John: Thank you for your clarification concerning ARIN policy at the AUP. As a judicial or administrative process it merits the classification status of "star chamber" which see reference: http://bit.ly/7j7UZu As you have confirmed John the AUP Committee may act in secret "and no notice is required before or after". This is unacceptable with respect to the allegations against me made here by you. Being that I have in some way caused the disruption of civil order and decorum on the mailing lists. Kindly ask the star chamber to detail what it is I have done that violated the AUP and I will apologist and promise never to do it again. But please don't keep my offense a secret. I demand the decision of the AUP concerning me be made public for all to see and admire and to assist me in making a proper signed apology. In other words I put you to the strict proof thereof. I also remind the star committee that it is I who has been libeled, slandered and defamed on an ARIN mailing list. And now I have been silenced? I think thats a bad omen and the action taken may be considered defamatory. I ask that the committee kindly consider that they may be contributing to further defamation of my character by their current actions. Furthermore I apologize for posting to the list when it is clear now to me that I should not have posted. I hold John Curran and the AUP Committee responsible for my actions in this. It is impossible to follow rules or rulings when they are kept secret from the person whom the ruling applies to. This has always been a problem with star chambers and secrecy. kindest regards joe baptista ________________________________ From: John Curran To: Not Doctor X ; Joe Baptista Cc: arin ppml Sent: Sat, January 16, 2010 12:43:26 PM Subject: Re: Mail postings from Joe Baptista held pending AUP Committee review Joe - First, you are mistaken, in that actions enforcing the AUP may be taken at any time and no notice is required before or after. At all times, ARIN reserves the right to maintain order and decorum on the mailing lists it manages, and your messages were being held awaiting review of the complaints. Second, the use of "Not Doctor X" is likely to be considered a fictitious name by many, but I'll leave that to the AUP committee to judge. You've been provided contact information for AUP Committee; free free to contact them, but in any case immediately cease posting to ARIN PPML (under any and all aliases) until informed otherwise. Thank you, /John John Curran President and CEO ARIN On Jan 16, 2010, at 12:15 PM, Not Doctor X wrote: Dear Mr. Curran: > >Thank you for the clarification. However I have received no notice from the AUP committee and it is my understanding my posting privileges can only be suspended once notice is made. > >I would also like an opportunity to respond to the complaint and would request that any complaints be provided to me. > >Next I did not post using a fictitious name. I made very clear I was the one posting. There was no attempt to defraud or deceive nor have I in any way violated the AUP. > >You have also suspended my posting privileges without notice and this suspension causes me the injured party in this further damage. This time by ARIN itself. > >regards >joe baptista > __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun Jan 17 09:56:02 2010 From: jcurran at arin.net (John Curran) Date: Sun, 17 Jan 2010 09:56:02 -0500 Subject: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review In-Reply-To: <788174.73831.qm@web113919.mail.gq1.yahoo.com> References: <921874.2184.qm@web113912.mail.gq1.yahoo.com> <5F4D6170-5773-4A35-A9E8-1EC887050042@arin.net> <788174.73831.qm@web113919.mail.gq1.yahoo.com> Message-ID: On Jan 17, 2010, at 9:24 AM, Not Doctor X wrote: John: Thank you for your clarification concerning ARIN policy at the AUP. As a judicial or administrative process it merits the classification status of "star chamber" which see reference: http://bit.ly/7j7UZu As you have confirmed John the AUP Committee may act in secret "and no notice is required before or after". This is unacceptable with respect to the allegations against me made here by you. Being that I have in some way caused the disruption of civil order and decorum on the mailing lists. Kindly ask the star chamber to detail what it is I have done that violated the AUP and I will apologist and promise never to do it again. But please don't keep my offense a secret. I demand the decision of the AUP concerning me be made public for all to see and admire and to assist me in making a proper signed apology. In other words I put you to the strict proof thereof. I also remind the star committee that it is I who has been libeled, slandered and defamed on an ARIN mailing list. And now I have been silenced? I think thats a bad omen and the action taken may be considered defamatory. I ask that the committee kindly consider that they may be contributing to further defamation of my character by their current actions. Furthermore I apologize for posting to the list when it is clear now to me that I should not have posted. I hold John Curran and the AUP Committee responsible for my actions in this. It is impossible to follow rules or rulings when they are kept secret from the person whom the ruling applies to. This has always been a problem with star chambers and secrecy. kindest regards joe baptista Joe - The AUP Committee performs the single focused administrative role of providing oversight to the staff process of AUP administration and is made up of both representatives of two elected bodies (Board of Trustees & ARIN Advisory Council) as well as one member appointed at large. It is not a judicial body in any sense; such remain available to you (and ARIN) if they prove necessary. On January 9th, you were informed specifically that your messages regarding Chris Mettin/GQHS were off-topic for the PPML list (see attached). Since that warning, you have repeatedly posted additional emails on that topic and unrelated to the Internet number resource policy. The ARIN Mailing Lists serve as a forum for particular subject matter and must remain focused on those topics to be useful to the community. The lists do not serve as your personal forum; please take your posts not directly related to number resource policy elsewhere. As noted, if you wish to correspond with the committee, you may contact the Chair or send email to the "aupabuse at arin.net" email address which will also reach them. Thank you, /John John Curran President and CEO ARIN === Begin forwarded message: From: John Curran > Date: January 9, 2010 9:12:49 PM EST To: Joe Baptista > Cc: arin ppml > Subject: Re: [arin-ppml] Christopher Mettin On Jan 8, 2010, at 8:36 AM, Joe Baptista wrote: John: First a belated thank you for the update from the AUP committee on Christopher Mettin the representative of the Gymnasium Querfurt High School. I have recently sent a formal notice to Christopher's principle Dr. Daumer demanding an apology for Christopher's defamatory comments against myself in which I requested a further apology be made by the school to the members here. FYI the letter in PDF can be seen at the following URL http://bit.ly/6q0r2g kindest regards joe baptista Joe - To the extent that you consider it your duty to keep the community informed in this matter, please consider that duty fully discharged at this point. It would be best if all would refrain from further email on this topic on the PPML list, as it is not relevant to the formation of public number resource policy. Thanks! /John John Curran President and CEO ARIN = _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Jan 17 10:46:03 2010 From: bill at herrin.us (William Herrin) Date: Sun, 17 Jan 2010 10:46:03 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> Message-ID: <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> On Sat, Jan 16, 2010 at 7:55 PM, Owen DeLong wrote: > On Jan 16, 2010, at 4:28 PM, Michael Richardson wrote: >> ?If techies need to get their managers to approve a checque to ARIN, >> the manager tells them to use IPv4 + NAT. ?If the techies do not have to >> ask, then they will deploy IPv6 for internal use. No joke on that. Three years ago my boss turned me down on deploying IPv6 in my spare time at work on the grounds that there were wiser ways to spend the $1250. >> ?(ULA buys you nothing compared to net-10) > 1. ? ? ?ULA buys you a great deal more than RFC-1918. ?ULA is statistically, > ? ? ? ?if not globally unique. Not exactly... The analysis in RFC 4193 (ULA addressing) section 3.2.3 is technically correct but it may be an example of "lies, damn lies and statistics." First, though de-emphasized in the RFC, the probability of collision has a phenomenal growth rate: two orders of magnitude for ever one order of magnitude increase in the number of ULA IDs. So you close in on a 100% chance of collision not at 2^40 IDs as you'd expect but at merely 2^20. Second, consider the way folks tend to behave. Each private network built for whatever purpose in a particular company will consume one or several ULA IDs. That's each private network in each project at each branch of a company. A large company may well have consumed hundreds if not thousands of ULA IDs introducing another four to six orders of magnitude increase in the probability of collision when two such companies want to connect. Practically speaking, we should start to see anecdotes about ULA collisions as folks try to connect 100 to 1000 organizations together, still a usefully large number but far fewer than RFC 4193 implies. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sun Jan 17 11:40:13 2010 From: bill at herrin.us (William Herrin) Date: Sun, 17 Jan 2010 11:40:13 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <4B4FA35F.9070804@arin.net> References: <4B4FA35F.9070804@arin.net> Message-ID: <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> On Thu, Jan 14, 2010 at 6:06 PM, Member Services wrote: > Policy Proposal 107: Rework of IPv6 assignment criteria As I read it, these are the main things accomplished by proposal 107: 1. Multihomed organizations now qualify for an ARIN /48 based solely on the fact that they're multihomed. This corrects the serious technical flaw in current policy where no IPv6 equivalent of NRPM 4.2.3.6 is usable in IPv6 for any practical definition of "usable." 2. Provides explicit address assignments for non-connected networks, supplementing ULA. 3. Removes the hard dependency on IPv4 policy for determining qualification for IPv6 end-user assignments by spelling out all the other reasonable criteria for qualification. What did I miss? I offer the following comments: 1. Proposal 106 is superior to and incompatible with proposal 107. I strongly prefer proposal 106. 2. I'm concerned about assignments to non-connected networks where qualification is based on the promise that they won't ever connect to the Internet and therefore won't introduce a route into the IPv6 backbone. If the promise is meant to be kept, I don't think such assignments should be made from address blocks within 2000::/3. 2000::/3 is intended to be the block used on the public Internet. Can ARIN readily acquire an address block outside of 2000::/3 for these assignments? Or perhaps assert a non-binding registry over a 32-bit section of ULA space? Let me be clear: I do not object to the use of 2000::/3 space for non-connected networks. I'm only concerned about the non-connectedness of a network qualifying its registrant for 2000::/3 addresses for which it would not otherwise qualify. I worry that will either lead to an end-run around the qualifications analysis for routed space or result in such a stringent review and high cost as to render the process useless for the non-connected networks which need addresses. Either result is a failure. I agree in principle with a registry for non-connected networks. ULA's statistical collision avoidance is not as effective as it appears. 3. I observe that advancing proposal 107 in parallel with 106 would avoid the potentially Faustian bargain of only correcting current IPv6 policy's obvious failings if folks also accept innovations like pools of fixed-netmask assignments. If the proposed 6.5.8.3 can be corrected and only if proposal 106 fails to achieve consensus, I will support proposal 107. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Sun Jan 17 13:04:14 2010 From: farmer at umn.edu (David Farmer) Date: Sun, 17 Jan 2010 12:04:14 -0600 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> References: <4B4FA35F.9070804@arin.net> <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> Message-ID: <4B53511E.8010103@umn.edu> William Herrin wrote: > On Thu, Jan 14, 2010 at 6:06 PM, Member Services wrote: >> Policy Proposal 107: Rework of IPv6 assignment criteria > > As I read it, these are the main things accomplished by proposal 107: > > 1. Multihomed organizations now qualify for an ARIN /48 based solely > on the fact that they're multihomed. This corrects the serious > technical flaw in current policy where no IPv6 equivalent of NRPM > 4.2.3.6 is usable in IPv6 for any practical definition of "usable." > > 2. Provides explicit address assignments for non-connected networks, > supplementing ULA. > > 3. Removes the hard dependency on IPv4 policy for determining > qualification for IPv6 end-user assignments by spelling out all the > other reasonable criteria for qualification. > > What did I miss? Those are what I intended. I would like to find a replacement for HD-Ratios too. But I haven't figured that out just yet and I'm not sure I'll be able to figure that our in time to make Toronto, besides very large proposal that change many different part of policy don't have a very good track record. > I offer the following comments: > > 1. Proposal 106 is superior to and incompatible with proposal 107. I > strongly prefer proposal 106. In some ways I agree with you and in other ways I disagree, but I have yet to decide if I prefer the direction of 106 to 107. But, I am by no means opposed to 106, I just think we need to consider all the options and pick the best one after considering all the implications. > 2. I'm concerned about assignments to non-connected networks where > qualification is based on the promise that they won't ever connect to > the Internet and therefore won't introduce a route into the IPv6 > backbone. If the promise is meant to be kept, I don't think such > assignments should be made from address blocks within 2000::/3. > 2000::/3 is intended to be the block used on the public Internet. > > Can ARIN readily acquire an address block outside of 2000::/3 for > these assignments? Or perhaps assert a non-binding registry over a > 32-bit section of ULA space? > > Let me be clear: I do not object to the use of 2000::/3 space for > non-connected networks. I'm only concerned about the non-connectedness > of a network qualifying its registrant for 2000::/3 addresses for > which it would not otherwise qualify. I worry that will either lead to > an end-run around the qualifications analysis for routed space or > result in such a stringent review and high cost as to render the > process useless for the non-connected networks which need addresses. > Either result is a failure. > > I agree in principle with a registry for non-connected networks. ULA's > statistical collision avoidance is not as effective as it appears. I understand the concern, I share it, I am open to suggestions. But, I believe that not providing resources to non-connected networks is a bigger risk for the successful transition to IPv6 than the risk of an end-run that this creates. How I was attempting to deal with this was to make the criteria for 6.5.8.2.c to be comparable, if not easier, to 6.5.8.3.b. If it is about the same amount of work or slightly easier to justify a single connected /48 as a non-connected /48 then why would you try to game the system? Suggestion or thoughts here would be greatly appreciated. > 3. I observe that advancing proposal 107 in parallel with 106 would > avoid the potentially Faustian bargain of only correcting current IPv6 > policy's obvious failings if folks also accept innovations like pools > of fixed-netmask assignments. This is exactly why I proposed this, I defiantly perceive the need for and support within the community for some major changes to IPv6 policy. My intent is for 106, 107 and a modified version of 101 to advance to Draft Policy to be discussed for adoption at Toronto. I'm working with Chris the original author of 101, Cathy and Bill as the AC shepherds for that proposal to get some new text out for allocation, in the spirit of 107. But, what actually happens is up to the whole AC. The AC really needs to here from the community on these issues so please let us know is you support any of these proposals, and what you want the AC to prepare for consideration at Toronto, etc... > If the proposed 6.5.8.3 can be corrected and only if proposal 106 > fails to achieve consensus, I will support proposal 107. > > Regards, > Bill Herrin It is just about time for me to watch the beginning of the Vikings Game, GO VIKINGS!!! Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From gbonser at seven.com Sun Jan 17 16:05:41 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 17 Jan 2010 13:05:41 -0800 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6assignment criteria In-Reply-To: <4B53511E.8010103@umn.edu> References: <4B4FA35F.9070804@arin.net><3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> <4B53511E.8010103@umn.edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72A1@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net On > Behalf Of David Farmer > > Those are what I intended. I would like to find a replacement for > HD-Ratios too. But I haven't figured that out just yet and I'm not > sure > I'll be able to figure that our in time to make Toronto, besides very > large proposal that change many different part of policy don't have a > very good track record. > > > I offer the following comments: > > > > 1. Proposal 106 is superior to and incompatible with proposal 107. I > > strongly prefer proposal 106. > > In some ways I agree with you and in other ways I disagree, but I have > yet to decide if I prefer the direction of 106 to 107. But, I am by no > means opposed to 106, I just think we need to consider all the options > and pick the best one after considering all the implications. We are an end user, not an ISP. We currently have three multihomed facilities and have at least one more in the US in the planning stages. The current policies are not clear. We asked for and obtained a /48 but now realize we should have asked for more space but weren't familiar with ipv6 addressing conventions. Under proposal 106 we would have asked for a /40. 107 is still somewhat ambiguous. A compromise between the two is that if an end user has multiple sites, just give them a /44 as that amount of space is going to be set aside for them anyway even if not issued immediately. It isn't as much as 106 would issue but a /44 would cover many organizations over their lifetime. This allows the end user with multiple sites that are multihomed to more easily aggregate addressing where possible (e.g. our current three sites are all in the SF Bay area and are interconnected so I could aggregate those in a single announcement to our upstream transit and our private peering) without having to come back to ARIN each time I need an additional /48 for another location. HD requirements have been painful for us as about 1/3 of our addressing is not internet reachable. These addresses are used for things such as private connections to business partners over encrypted VPN or direct physical connections. It gets hard to "prove" to someone that we are using the address space when they do a simple address scan of the network and come up with significantly less than we say we are using. Our policies and those of our partners dictate that unique global addressing be used for these connections to prevent collisions in local addressing between our networks. HD requirements are probably good for justifying additional space for growth at a static number of facilities but when address space is requested in order to support additional facilities, the HD requirement doesn't really apply if one is to use a /48 per facility. And this would apply whether or not the new site is a discreet network or integrated with a common backbone. Splitting a /48 between locations seems like a bad idea and as far as I can tell, the current "best practice" is to use a /48 per location. My suggestion would be to remove the HD requirement in 107 for initial assignments to end users with multiple locations and simply issue them the /44 block that 107 reserves. For an end user with a single location, the language in 107 is probably fine. Or simply go with 106 which gives everyone a /48 or a /40 but after having to live with v4 scarcity so long seems somehow wasteful. I just want enough address space to number all my facilities in their own /48 without having to do the ARIN dance every time I add a new one. From mcr at sandelman.ca Sun Jan 17 17:10:54 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 17 Jan 2010 17:10:54 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: References: <4B4FA35F.9070804@arin.net> <30233.1263585412@marajade.sandelman.ca> <4B514E08.30209@umn.edu> <776.1263689059@marajade.sandelman.ca> <4B527263.7090406@umn.edu> Message-ID: <27640.1263766254@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: Owen> How about this: Owen> 6.5.8.4 Initial Assignments to Community Networks Owen> Organizations may receive an initial assignment for operating Owen> a Community Network after documenting that they meet the Owen> criteria specified in section 2.11. Seems nice and DRY. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From marty at akamai.com Sun Jan 17 17:37:20 2010 From: marty at akamai.com (Martin Hannigan) Date: Sun, 17 Jan 2010 17:37:20 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> Message-ID: On Jan 15, 2010, at 4:33 PM, Davis, Terry L wrote: > > [ snip ] > If I represented an IT or comm vendor right now, I'd be doing > everything I could to get IPv6 used, including completely re- > thinking or totally opening up the allocation policies and reducing > the costs to near zero, just to protect my investments. > Interesting. Here is the fee schedule, Terry: X-small $1,250 /48 to /41 Small $2,250 /40 to /32 Medium $4,500 /31 to /30 Large $9,000 /29 to /27 X-large $18,000 /26 to /22 XX-large $36,000 Larger than /22 Which one is too expensive for your actual needs? -M< From mysidia at gmail.com Sun Jan 17 18:29:24 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 17 Jan 2010 17:29:24 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> Message-ID: <6eb799ab1001171529y2ce31c27h88fda22699ba3383@mail.gmail.com> On Sun, Jan 17, 2010 at 9:46 AM, William Herrin wrote: >> If techies need to get their managers to approve a checque to ARIN, >> the manager tells them to use IPv4 + NAT. If the techies do not have to >> ask, then they will deploy IPv6 for internal use. > No joke on that. Three years ago my boss turned me down on deploying > IPv6 in my spare time at work on the grounds that there were wiser > ways to spend the $1250. Is it not true that there was a 100% waiver of the IPv6 fees in the later half of 2007? https://www.arin.net/fees/fee_schedule.html#waivers Personally, I think ARIN should offer something like a 2-year deferral of IPv6 fees, in addition to the partial waiver. In other words: fees related to IPv6 assignments will not actually be due until 2012 on the anniversary date. If you cancel and return the initial allocation, no fees will be charged related to initial assignment/transfer of IPv6 addresses (additional transfers still cost). If you retain the allocation, you owe all the deferred charges. If IPv6 solves the problem, you pay. If not, and everyone resorts to IPv4+NAT, you don't. Thereby reducing the risk of applying for a resource for test purposes... -- -J From bill at herrin.us Sun Jan 17 18:48:07 2010 From: bill at herrin.us (William Herrin) Date: Sun, 17 Jan 2010 18:48:07 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <6eb799ab1001171529y2ce31c27h88fda22699ba3383@mail.gmail.com> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> <6eb799ab1001171529y2ce31c27h88fda22699ba3383@mail.gmail.com> Message-ID: <3c3e3fca1001171548v304720b3xc71ed9150c073b22@mail.gmail.com> On Sun, Jan 17, 2010 at 6:29 PM, James Hess wrote: > On Sun, Jan 17, 2010 at 9:46 AM, William Herrin wrote: >>> ?If techies need to get their managers to approve a checque to ARIN, >>> the manager tells them to use IPv4 + NAT. ?If the techies do not have to >>> ask, then they will deploy IPv6 for internal use. >> No joke on that. Three years ago my boss turned me down on deploying >> IPv6 in my spare time at work on the grounds that there were wiser >> ways to spend the $1250. > > Is it not true that there was a 100% ?waiver of the ? IPv6 ?fees ?in > the later half of 2007? James, Now that you mention it, there was some kind of waiver in place because I remember arguing the case that it would be cheaper to get the addresses then instead of waiting. But it wasn't a total waiver, at least not for end-user assignments, because if I wouldn't have bothered to ask. The current waiver, of course, does not apply to end-user assignments at all. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sun Jan 17 18:50:49 2010 From: bill at herrin.us (William Herrin) Date: Sun, 17 Jan 2010 18:50:49 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <4B53511E.8010103@umn.edu> References: <4B4FA35F.9070804@arin.net> <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> <4B53511E.8010103@umn.edu> Message-ID: <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> On Sun, Jan 17, 2010 at 1:04 PM, David Farmer wrote: > I would like to find a replacement for HD-Ratios > too. ?But I haven't figured that out just yet My observation here is that IPv6 addressing seems to be LAN-centric rather than host-centric. That is, it's driven by the number of /64 LANs deployed rather than the number of individual computers. >> 2. I'm concerned about assignments to non-connected networks where >> qualification is based on the promise that they won't ever connect to >> the Internet and therefore won't introduce a route into the IPv6 >> backbone. If the promise is meant to be kept, I don't think such >> assignments should be made from address blocks within 2000::/3. >> 2000::/3 is intended to be the block used on the public Internet. > > I understand the concern, I share it, I am open to suggestions. Speaking off the cuff, I think I'd shape it like this: 1. Ask IANA for a /16 delegation of of the existing ULA space, e.g. FC42::/16.Failing that, simply assert regiistration over a portion of ULA space e.g. FD42::/16. 2. With a mostly automated web-based system, accept registration of /48's within the space. 3. A registration account costs $10/year. No concept of organizations; just accounts each billed seperately. 4. All /48's in the account must be contiguous to the maximum extent possible. Each /48 registered costs an additional $1/year. In ULA parlance, each /48 is "one Global ID." 5. Private registration available if desired at no cost. If private, ARIN will publish a relay email address that can be used to contact the registrant's real email address. They'll publish no other information. After all, do we really need to know that the DOJ is using a particular range of private IP addresses privately inside their private system? I don't think we do. 6. RNDS delegation in the public DNS if desired. Let the registrants decide for themselves if they want leaky name lookups to lead back inside. Could be very helpful in a large private network where you don't want every participant to have to plug lots of exceptions into his DNS server. 7. Registration is non-binding. ARIN guarantees only that if both networks participate in registration then they won't have conflicting address use. The $10 supports operating a heavily automated registry. The $1 provides mild back-pressure against wasteful consumption of /48's. The contiguity requirement mildly encourages smart aggregation practices. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mcr at sandelman.ca Sun Jan 17 20:55:00 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 17 Jan 2010 20:55:00 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> References: <4B4FA35F.9070804@arin.net> <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> <4B53511E.8010103@umn.edu> <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> Message-ID: <11434.1263779700@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "William" == William Herrin writes: William> Speaking off the cuff, I think I'd shape it like this: William> 1. Ask IANA for a /16 delegation of of the existing ULA William> space, e.g. It would work for me. It's ULA-C, basically. William> 3. A registration account costs $10/year. No concept of William> organizations; William> just accounts each billed seperately. There are 4B /48s there. Enough for several for each person now alive in the ARIN region. William> 6. RNDS delegation in the public DNS if desired. Let the I would like RDNS (others may need it). I would like whois. I would be happy with the proxy-contact-address for these --- I have numerous experiences with enterprises (not always after a merge!!!), where things do not overlap, but suddendly, another set of previously unknown rfc1918 addresses start to show up, and nobody knows from where. The overlapping case is actually less of a problem. William> 7. Registration is non-binding. ARIN guarantees only that if both William> networks participate in registration then they won't have William> conflicting address use. I'm not sure I get what non-binding means here. William> The $10 supports operating a heavily automated registry. William> The $1 provides mild back-pressure against wasteful William> consumption of /48's. Agreed. However, realize that we basically can never get these addresses back. My position might be... if you stop paying the fee, then the registration information that was previously private, becomes public. (maybe) William> The contiguity requirement mildly encourages smart William> aggregation practices. I do not know why this is important. These are networks that can never appear in the DFZ. They may appear in various COINs, VPNs, enterprises, or personal-area networks. 64K subnets is enough for many, and anyone with that many routes (a COIN or VPN with 256 sites of 256 subnets...) won't be very worried that their second /48 does not aggregate with their first /48, I think. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS1O/c4CLcPvd0N1lAQLQlgf/UF/5n5KR7s1e1A2SUBIRkvPyC5s/tZtp y2dUnw44+bmhNBA4DEVdAYlJ8NGe1yYXiRmHhR0UhJxSLzdA2Tm2nJxqtbV/NIXT /SmxG16Jjgdg62HxYncL+m7IiexJLvadYS8LhqnEhV8FZOgExBYnD2SrM34w7B9i F4hbBkP4EVQFDSJg54tiwPwXGZMvw6YQm7AhIeS1wu5D2Fl/M99v9NBSOelN+uol T0/9K4SnoRh32L6K7HO7TPwyPpXuVV0hNh1x5RvGV9N3lxbCYcVhOfWoO6crozx/ z+Y/c2mbc2JXprng4Crgh7FE2F45fzQokMyVlACGWI5hutQol915dw== =ZBVU -----END PGP SIGNATURE----- From owen at delong.com Sun Jan 17 21:27:56 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Jan 2010 18:27:56 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> Message-ID: <973D0AE1-738A-4E65-B359-E022CE792D71@delong.com> On Jan 17, 2010, at 7:46 AM, William Herrin wrote: > On Sat, Jan 16, 2010 at 7:55 PM, Owen DeLong wrote: >> On Jan 16, 2010, at 4:28 PM, Michael Richardson wrote: >>> If techies need to get their managers to approve a checque to ARIN, >>> the manager tells them to use IPv4 + NAT. If the techies do not have to >>> ask, then they will deploy IPv6 for internal use. > > No joke on that. Three years ago my boss turned me down on deploying > IPv6 in my spare time at work on the grounds that there were wiser > ways to spend the $1250. > > >>> (ULA buys you nothing compared to net-10) >> 1. ULA buys you a great deal more than RFC-1918. ULA is statistically, >> if not globally unique. > > Not exactly... The analysis in RFC 4193 (ULA addressing) section 3.2.3 > is technically correct but it may be an example of "lies, damn lies > and statistics." > > First, though de-emphasized in the RFC, the probability of collision > has a phenomenal growth rate: two orders of magnitude for ever one > order of magnitude increase in the number of ULA IDs. So you close in > on a 100% chance of collision not at 2^40 IDs as you'd expect but at > merely 2^20. > So for every 2 companies merging, you run the risk of a 1:2^20 collision. Now, let's look at those odds in numbers more meaningful to people... 2^20 is 1024^2, or, 1,048,576, so, the odds are, literally not quite as good as 1 in a million of any two companies colliding. I would argue that the odds of a collision in RFC-1918 are a lot closer to 1:3 at best since almost everyone uses at least one of 10.0.0.0/24, 172.16.0.0/24 or 192.168.0.0/24 (or some supernet thereof). So, in order for ULA to buy you nothing, you'd have to be able to argue that 1:3 and 1:1,048,576 are equivalent risks. If you are willing to make bets like that, I want to be your bookie. > Second, consider the way folks tend to behave. Each private network > built for whatever purpose in a particular company will consume one or > several ULA IDs. That's each private network in each project at each > branch of a company. A large company may well have consumed hundreds > if not thousands of ULA IDs introducing another four to six orders of > magnitude increase in the probability of collision when two such > companies want to connect. > Even if this is true (I'm not completely convinced), you're comparing ULA at 1:100 Practically speaking, we should start to see anecdotes about ULA > collisions as folks try to connect 100 to 1000 organizations together, > still a usefully large number but far fewer than RFC 4193 implies. > Practically speaking, even if you buy into that argument, you're still quite a bit better off than RFC-1918. 1. The odds of a collision are still about 300,000 times better. 2. The percentage of hosts likely to be affected by such a collision is orders of magnitude better than RFC-1918. 3. The above all assumes not using the SIXXS ULA registry to keep your ULA addresses unique. Owen From owen at delong.com Sun Jan 17 21:49:14 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Jan 2010 18:49:14 -0800 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> References: <4B4FA35F.9070804@arin.net> <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> <4B53511E.8010103@umn.edu> <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> Message-ID: <6C8D563B-DDC9-4422-873D-412A610ECA4C@delong.com> On Jan 17, 2010, at 3:50 PM, William Herrin wrote: > On Sun, Jan 17, 2010 at 1:04 PM, David Farmer wrote: >> I would like to find a replacement for HD-Ratios >> too. But I haven't figured that out just yet > > My observation here is that IPv6 addressing seems to be LAN-centric > rather than host-centric. That is, it's driven by the number of /64 > LANs deployed rather than the number of individual computers. > Correct. In current policy (and hopefully any future policy) host count is irrelevant. An IPv6 /64 allows for several undecillion hosts in each network, so, the number of hosts becomes far less relevant. > >>> 2. I'm concerned about assignments to non-connected networks where >>> qualification is based on the promise that they won't ever connect to >>> the Internet and therefore won't introduce a route into the IPv6 >>> backbone. If the promise is meant to be kept, I don't think such >>> assignments should be made from address blocks within 2000::/3. >>> 2000::/3 is intended to be the block used on the public Internet. >> >> I understand the concern, I share it, I am open to suggestions. > > Speaking off the cuff, I think I'd shape it like this: > > 1. Ask IANA for a /16 delegation of of the existing ULA space, e.g. > FC42::/16.Failing that, simply assert regiistration over a portion of > ULA space e.g. FD42::/16. > Personally, I would rather see us move in the direction of making no distinction between numbers for connected and disconnected networks. Unless you want to put ARIN in the role of gatekeeper to the routing table (which I think is a bad idea), there's no need for such a distinction. > 2. With a mostly automated web-based system, accept registration of > /48's within the space. > > 3. A registration account costs $10/year. No concept of organizations; > just accounts each billed seperately. > > 4. All /48's in the account must be contiguous to the maximum extent > possible. Each /48 registered costs an additional $1/year. In ULA > parlance, each /48 is "one Global ID." > This pricing strategy, while interesting, isn't particularly relevant to a policy discussion. If you want to talk about fees ARIN should charge, I believe it is better suited to the arin-discuss list. > 5. Private registration available if desired at no cost. If private, > ARIN will publish a relay email address that can be used to contact > the registrant's real email address. They'll publish no other > information. After all, do we really need to know that the DOJ is > using a particular range of private IP addresses privately inside > their private system? I don't think we do. > Depends on whether it leaks into the global routing table or not. If it does, it's good to know who to call and say "Did you mean to do this? If so, you're using the wrong prefix. If not, review your configuration." > 6. RNDS delegation in the public DNS if desired. Let the registrants > decide for themselves if they want leaky name lookups to lead back > inside. Could be very helpful in a large private network where you > don't want every participant to have to plug lots of exceptions into > his DNS server. > Yep... Alsouseful for the organization that built out a huge "non- connected" network that later needs to connect and they'd rather bribe their ISP than renumber. > 7. Registration is non-binding. ARIN guarantees only that if both > networks participate in registration then they won't have conflicting > address use. > Should there be inter-RIR cooperation on this such that if you participate in ARIN registration, you're not going to conflict with APNIC registrants? If so, this probably requires a global or globally coordinated proposal. Owen From mysidia at gmail.com Sun Jan 17 22:07:55 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 17 Jan 2010 21:07:55 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <973D0AE1-738A-4E65-B359-E022CE792D71@delong.com> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> <973D0AE1-738A-4E65-B359-E022CE792D71@delong.com> Message-ID: <6eb799ab1001171907h2f54c655r9e54f41532430993@mail.gmail.com> On Sun, Jan 17, 2010 at 8:27 PM, Owen DeLong wrote: > On Jan 17, 2010, at 7:46 AM, William Herrin wrote: >> On Sat, Jan 16, 2010 at 7:55 PM, Owen DeLong wrote: ... >> Practically speaking, we should start to see anecdotes about ULA >> collisions as folks try to connect 100 to 1000 organizations together, >> still a usefully large number but far fewer than RFC 4193 implies. > Practically speaking, even if you buy into that argument, you're still > quite a bit better off than RFC-1918. If you have a V6 ULA collision, you may be a lot worse off than you were with a IPv4 RFC-1918 collision. The thing is: you can probably mitigate an RFC-1918 collision (when merging companies, for example), by using creative NAT rewriting rules; NAT'ing both sources and destinations, to provide connectivity for the transition period, when the merging companies renumber to eliminate conflicts. In the IPv6 world, so far, there is no such thing as NAT. You cannot use NAT or translation to mitigate an address space collision, when the tool and even the specification has not been created.. A RFC-1918 collision can be much less of an issue than a ULA collision, even though it is more likely. So the combination of IPv6 + ULA can make you a lot worse off in some scenarios. When the specifications for IPv6 NAT come out, and vendors start making equipment that can NAT map a block of V6 addresses 1:1 into another block of addresses, _then_ we can consider you a lot better off with ULA in that scenario. .. >> > So, in order for ULA to buy you nothing, you'd have to be able to argue > that 1:3 and 1:1,048,576 are equivalent risks. If you are willing to make > bets like that, I want to be your bookie. > Even if this is true (I'm not completely convinced), you're comparing > ULA at 1:100; from William Herrin on Sun, Jan 17, 2010 at 10:46:03AM -0500 References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> Message-ID: <20100117220236.W15024@AegisInfoSys.com> On Sun, Jan 17, 2010 at 10:46:03AM -0500, William Herrin wrote: > Not exactly... The analysis in RFC 4193 (ULA addressing) section 3.2.3 > is technically correct but it may be an example of "lies, damn lies > and statistics." Is it shorthand for the Birthday Paradox (http://en.wikipedia.org/w/index.php?title=Birthday_problem)? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York (800) AEGIS-00 From mysidia at gmail.com Sun Jan 17 22:37:52 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 17 Jan 2010 21:37:52 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100117220236.W15024@AegisInfoSys.com> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> <20100117220236.W15024@AegisInfoSys.com> Message-ID: <6eb799ab1001171937p1a6e02cdja71f9f0ad3183869@mail.gmail.com> On Sun, Jan 17, 2010 at 9:02 PM, Henry Yen wrote: > On Sun, Jan 17, 2010 at 10:46:03AM -0500, William Herrin wrote: >> Not exactly... The analysis in RFC 4193 (ULA addressing) section 3.2.3 >> is technically correct but it may be an example of "lies, damn lies >> and statistics." > > Is it shorthand for the Birthday Paradox > (http://en.wikipedia.org/w/index.php?title=Birthday_problem)? And the RFC accounts for that, by using the formula Exp[-N^2 / 2^41] http://tools.ietf.org/html/rfc4193#section-3.2.3 However... I wonder how 'random' the 40-bit global ID will actually be in practice. I realize the RFC suggests a robust procedure for generating it.. But something tells me many sites will be tempted to ignore those recommendations, and treat ULA much like they treat RFC-1918 addresses. That is, they might confuse "random id", for just pick whatever number occurs to them. Statistically more than should will probably pick all-bits zero, or 'some convenient numbers' for the global id field. Or even, a human picking the global ID might _avoid_ numbers like 0 or 1234, such that the number has less than a 1/2^40 chance of being picked. If the actual entropy behind 'global id creation' in practice turns out to be less than true randomness, then the results regarding probabiliity of collision are also fallible. -- -J From gbonser at seven.com Mon Jan 18 00:18:07 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 17 Jan 2010 21:18:07 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <6eb799ab1001171937p1a6e02cdja71f9f0ad3183869@mail.gmail.com> References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca><0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><32154.1263688132@marajade.sandelman.ca><3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com><20100117220236.W15024@AegisInfoSys.com> <6eb799ab1001171937p1a6e02cdja71f9f0ad3183869@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72AC@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net On > Behalf Of James Hess > Sent: Sunday, January 17, 2010 7:38 PM > > However... I wonder how 'random' the 40-bit global ID will > actually be in practice. > If the actual entropy behind 'global id creation' in practice > turns out to be less than true randomness, then the results > regarding probabiliity of collision are also fallible. > > -- > -J I agree. People needing just one net are likely to use the first net of the block for local assignment or number facilities sequentially even though they are asked not to. I suppose the RIR's could issue space out of FC00::/8 to anyone who asks and people still have FD00::/8 to use as they wish. That would mean no chance of a collision in FC00::/8 unless connecting to someone numbered from a different RIR. It's one more thing for the RIR's to keep track of, though. Basically it means changing the L bit to mean 1=assigned by the organization 0=assigned by the organization's RIR From michael.dillon at bt.com Mon Jan 18 05:36:12 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Jan 2010 10:36:12 -0000 Subject: [arin-ppml] Policy Proposal 107: Rework ofIPv6assignment criteria In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72A1@RWC-EX1.corp.seven.com> Message-ID: <28E139F46D45AF49A31950F88C49745804D449A4@E03MVZ2-UKDY.domain1.systemhost.net> >I just want enough address space to number all my facilities in their own /48 >without having to do the ARIN dance every time I add a new one. Sounds like an ISP to me. Apply for your /32 and get on with it. --Michael Dillon From mcr at sandelman.ca Mon Jan 18 08:40:03 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 18 Jan 2010 08:40:03 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <6C8D563B-DDC9-4422-873D-412A610ECA4C@delong.com> References: <4B4FA35F.9070804@arin.net> <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> <4B53511E.8010103@umn.edu> <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> <6C8D563B-DDC9-4422-873D-412A610ECA4C@delong.com> Message-ID: <1074.1263822003@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Owen" == Owen DeLong writes: >> Speaking off the cuff, I think I'd shape it like this: >> >> 1. Ask IANA for a /16 delegation of of the existing ULA space, e.g. >> FC42::/16.Failing that, simply assert regiistration over a portion of >> ULA space e.g. FD42::/16. >> Owen> Personally, I would rather see us move in the direction of making no Owen> distinction between numbers for connected and disconnected networks. Owen> Unless you want to put ARIN in the role of gatekeeper to the routing Owen> table (which I think is a bad idea), there's no need for such Owen> a distinction. I disagree. The lack of distinction is what makes ARIN the role of gatekeeper. If all addresses can go into the DFZ, then there has to be criteria appropriate on *ALL* allocations that says, "This might show up". If there is a distinction, then there is no concern. In fact, if there is a distinction, not only is there no concern about end-run-around, but it is also possible to make the criteria stronger, and push more PA addressing to many organizations which presently own their own IPv4 address space, but are not really multihomed. (Serially multihomed... akin to serial monogamy...) >> 2. With a mostly automated web-based system, accept registration of >> /48's within the space. >> >> 3. A registration account costs $10/year. No concept of organizations; >> just accounts each billed seperately. >> >> 4. All /48's in the account must be contiguous to the maximum extent >> possible. Each /48 registered costs an additional $1/year. In ULA >> parlance, each /48 is "one Global ID." Owen> This pricing strategy, while interesting, isn't particularly Owen> relevant to a policy discussion. If you want to talk about Owen> fees ARIN should Owen> charge, I believe it is better suited to the arin-discuss Owen> list. I disagree strongly. >> 5. Private registration available if desired at no cost. If private, >> ARIN will publish a relay email address that can be used to contact >> the registrant's real email address. They'll publish no other >> information. After all, do we really need to know that the DOJ is >> using a particular range of private IP addresses privately inside >> their private system? I don't think we do. Owen> Depends on whether it leaks into the global routing table or not. If clearly labelled can not leak into the global routing table. >> 6. RNDS delegation in the public DNS if desired. Let the registrants >> decide for themselves if they want leaky name lookups to lead back >> inside. Could be very helpful in a large private network where you >> don't want every participant to have to plug lots of exceptions into >> his DNS server. >> Owen> Yep... Alsouseful for the organization that built out a huge "non- Owen> connected" network that later needs to connect and they'd rather Owen> bribe their ISP than renumber. If clearly labelled, the ISP simple can not take the bribe. That's good for *ALL* of us. >> 7. Registration is non-binding. ARIN guarantees only that if both >> networks participate in registration then they won't have conflicting >> address use. Owen> Should there be inter-RIR cooperation on this such that if you Owen> participate Owen> in ARIN registration, you're not going to conflict with APNIC Owen> registrants? Owen> If so, this probably requires a global or globally coordinated Owen> proposal. Yes, it has to be coordinated, no this is not such a big deal. There are enough bits to go around. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS1RksICLcPvd0N1lAQKzxgf/ZsOoUbGfLkV3bpa6CqrYbaJBbxXXGeEC l6QqHpUybBlFRWWOOB7jixLOyGlz/3MxxeMeHEB+MiCgmQi20SHoB5k9OTF4yDOD 7rdEtz9lr1ZxuTrk6cbBcPTp29lgCzwaxf0y7ainMvxwKkPn2oj67PAL8y3XgxMU JGeucC+AVKaBs9p8nQBLD/wScwm3M17/2wJmH5DHQxbO9O+Df/KY/KdsdAKW+Kp8 Q7C7VbZ/IOq5mFzShvHs525hc04mGUMK947VUhcu79ZANpqmIIrlC6dIkhNqy5eB IaPCZKwnbFgo8CXRRTZI81PdJ3zqO/1CEFDmBPtJ0Yqpq4VNrkK2iQ== =i3k2 -----END PGP SIGNATURE----- From terry.l.davis at boeing.com Mon Jan 18 09:37:17 2010 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 18 Jan 2010 06:37:17 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> Martin We are fine. 6 or 7 years back we got ours. For small companies, start ups, or lab use, even fees of this scale is often a make or break. We grew our IP infrastructure out of our labs. It would have taken off much slower here if a few of us couldn't have simply emailed in to request public IPv4 class C's for our lab environments; it would have been hard to justify paying for addresses back then. Take care Terry > -----Original Message----- > From: Martin Hannigan [mailto:marty at akamai.com] > Sent: Sunday, January 17, 2010 2:37 PM > To: Davis, Terry L > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] V6 address allocation policy > > > On Jan 15, 2010, at 4:33 PM, Davis, Terry L wrote: > > > > > > [ snip ] > > > If I represented an IT or comm vendor right now, I'd be doing > > everything I could to get IPv6 used, including completely re- > > thinking or totally opening up the allocation policies and > reducing > > the costs to near zero, just to protect my investments. > > > > > > Interesting. Here is the fee schedule, Terry: > > X-small $1,250 /48 to /41 > Small $2,250 /40 to /32 > Medium $4,500 /31 to /30 > Large $9,000 /29 to /27 > X-large $18,000 /26 to /22 > XX-large $36,000 Larger than /22 > > Which one is too expensive for your actual needs? > > > -M< > > > > > > > From sbarber at theplanet.com Mon Jan 18 09:36:57 2010 From: sbarber at theplanet.com (Barber, Stan) Date: Mon, 18 Jan 2010 08:36:57 -0600 Subject: [arin-ppml] V6 address allocation policy References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <8FF49FA5103C8D4DB1933ECE41EB477F04823521@HOUEXCH01.PLANET.LOCAL> <32402.1263688306@marajade.sandelman.ca> Message-ID: <8FF49FA5103C8D4DB1933ECE41EB477F04823522@HOUEXCH01.PLANET.LOCAL> Yes, that's what I understand to be the case. -----Original Message----- From: Michael Richardson [mailto:mcr at sandelman.ca] Sent: Sat 1/16/2010 6:31 PM To: Barber, Stan Cc: Davis, Terry L; arin-ppml at arin.net Subject: Re: [arin-ppml] V6 address allocation policy >>>>> "Stan" == Stan Barber writes: Stan> Terry, NTT has a large v6 deployment to the home in Japan Stan> called Hakari-TV. This is a walled-garden deployment for VOD Stan> (and other related features) to the home. By "walled garden", do you mean that the address space is not globally routed? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbarber at theplanet.com Mon Jan 18 09:45:12 2010 From: sbarber at theplanet.com (Barber, Stan) Date: Mon, 18 Jan 2010 08:45:12 -0600 Subject: [arin-ppml] V6 address allocation policy References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca><0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><8FF49FA5103C8D4DB1933ECE41EB477F04823521@HOUEXCH01.PLANET.LOCAL><32402.1263688306@marajade.sandelman.ca> <8FF49FA5103C8D4DB1933ECE41EB477F04823522@HOUEXCH01.PLANET.LOCAL> Message-ID: <8FF49FA5103C8D4DB1933ECE41EB477F04823523@HOUEXCH01.PLANET.LOCAL> By the way, I don't know the addressing scheme personally, so I don't know if they created it using globally routable addresses and choose not to route them or using space reserved for private addressing. I am sure Cody could tell you if you want to contact him. -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Barber, Stan Sent: Mon 1/18/2010 8:36 AM To: Michael Richardson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] V6 address allocation policy Yes, that's what I understand to be the case. -----Original Message----- From: Michael Richardson [mailto:mcr at sandelman.ca] Sent: Sat 1/16/2010 6:31 PM To: Barber, Stan Cc: Davis, Terry L; arin-ppml at arin.net Subject: Re: [arin-ppml] V6 address allocation policy >>>>> "Stan" == Stan Barber writes: Stan> Terry, NTT has a large v6 deployment to the home in Japan Stan> called Hakari-TV. This is a walled-garden deployment for VOD Stan> (and other related features) to the home. By "walled garden", do you mean that the address space is not globally routed? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Mon Jan 18 09:51:18 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Jan 2010 14:51:18 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <8FF49FA5103C8D4DB1933ECE41EB477F04823522@HOUEXCH01.PLANET.LOCAL> Message-ID: <28E139F46D45AF49A31950F88C49745804DC53AC@E03MVZ2-UKDY.domain1.systemhost.net> There is lots of interesting info available in English if you google hakari-tv ipv6 --Michael Dillon -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Barber, Stan Sent: 18 January 2010 14:37 To: Michael Richardson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] V6 address allocation policy Yes, that's what I understand to be the case. -----Original Message----- From: Michael Richardson [mailto:mcr at sandelman.ca] Sent: Sat 1/16/2010 6:31 PM To: Barber, Stan Cc: Davis, Terry L; arin-ppml at arin.net Subject: Re: [arin-ppml] V6 address allocation policy >>>>> "Stan" == Stan Barber writes: Stan> Terry, NTT has a large v6 deployment to the home in Japan Stan> called Hakari-TV. This is a walled-garden deployment for VOD Stan> (and other related features) to the home. By "walled garden", do you mean that the address space is not globally routed? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From terry.l.davis at boeing.com Mon Jan 18 09:52:08 2010 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 18 Jan 2010 06:52:08 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B50EAD9.2010506@ipinc.net> References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman. ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <4B50EAD9.2010506@ipinc.net> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B099A@XCH-NW-05V.nw.nos.boeing.com> Ted OS/2 isn't really a good example; I supported some of that for years. IBM tried to make "windows" for the enterprise with enterprise bells and whistles; it was to expensive for the masses and you had to be a pretty darn good sys-adim to set it up. Or maybe it is a good example of what we did with v6? As to HDTV, the USG provided a cheap shim to let folks decide on their own when to buy an HDTV. In the case of v6, we forgot the shim entirely; and $40 per app would be really good cheap shim even though we have two or more orders of magnitude of v4 apps to convert now than legacy TV's. I agree we can probably extend the runout some few number of years; my concern remains that all the new apps are still being written mostly without any v6 built in support for future conversion. Take care Terry > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Friday, January 15, 2010 2:23 PM > To: Davis, Terry L > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] V6 address allocation policy > > Davis, Terry L wrote: > > I've been a big supporter of IPv6 for a decade now since I > was in the > > FTTH business for awhile in 2000-2001. Industry has spent an > > enormous amount in developing it both in network and in the end > > systems. And I still feel it has huge potentials to allow us to > > improve the Internet. > > > > But yet even with the globe rushing headlong toward the end of IPv4 > > space, probably within 24 months, v6 is still barely > crawling forward > > in deployments. It's not going into greenfields, startups, etc. It > > is still hard to find native v6 transport. I don't know of a v6 > > network anywhere approaching even approaching 100,000 > systems (I hope > > I'm wrong!) on the globe. > > > > Yea I finally realized in doing my Master's paper a couple > years back > > that we had really screwed up by not defining a native way to allow > > v4 to v6 communications. > > Not true. I used to run OS/2. Remember that? OS/2 Warp? > > Well let me tell you something about transitions. IBM knocked > themselves out adding seamless windows support into OS/2 Warp. > They really wanted to be able to say that Warp ran Windows > better than Windows does. And they succeeded so well that > their software partners - like DeScribe - who for years ONLY > produced OS/2 versions of software, ended up going out of > business because all the Warp users out there simply used > their legacy Windows applications under OS/2 and never bothered > switching to OS/2 apps. Why would they, when Windows apps worked so > well under OS/2? > > Some things call for backwards-compatibility. Some things instead > call for making it very painful for the customers so that they are > forced to spend money to upgrade - because their upgrades are for > the greater good of the community. The customers who refuse to > upgrade are then cast-aside, they are winnowed out. It may seem > unfair - but to this day there's still people out there who have > refused to give up their Commodore 64's and buy PCs. That is > just a fact of life with change. Some people refuse to accept it > and will just continue on with what they know - until they are > among a small minority, and then they die of old age. > > Look at the HDTV business. We all know the US Government > gave everyone > free converter boxes to get their crappy old TV sets to work > on HD. But, the US Government DID NOT pay for anyone to get a > brand new HDTV UHF antenna, even though millions of people were > running set-top rabbit ears, or VHF antennas on the top of their > roofs. And those millions of people were basically told you > go spend $35 on a new Channel Master UHF antenna and find some > handyman to climb around on the top of your roof and install it. > We aren't going to make the signal backwards compatible to > your old VHF > antenna because we know damn well you wouldn't lift a finger > to replace > your antenna. > > We know that customers aren't going to spend money unless they > have to. Sometimes you just gotta be a hard-ass and don't give > them a choice to NOT spend the money. This is one of those times. > > > As is, you basically have to open every v4 > > app and re-write it to utilize v6; > > correct > > > none of the existing transition > > technologies cover all the v4 to v6 communications scenarios. With > > this much installed v4, the cost of opening every existing app to > > change it to be dual-stacked is staggering. > > > > That doesn't matter. All of those apps your talking about are > going to be obsolete in 20 years and replaced by new versions so > that staggering cost is going to be spent either way. > > > We can argue endlessly about the risks of opening v6 address > > allocation policy but in the end, if we cannot get the Internet > > developers to utilize it, all the investment of the IT and comm > > vendors will be lost. One of the alternatives to IPv6 will win (geo > > routing, 5th octet, something-out-of-the-blue, etc) and all that > > investment in IPv6 and its potential enhancements to the Internet > > will be lost to us. > > > > If you really think that an alternative to IPv6 has a chance then > where are all those startup software companies writing to one of > those alternative standards? Why isn't Microsoft pushing one of > those? > > out-of-the-blue laboratory curiosities implemented on Linux just > aren't going to make any difference. The future is IPv6 and > all the big players are betting on it, and the economic > situation in the world right now is not such that anyone is > going to put any real money into an alternative. > > The question isn't whether it's going to be IPv6 vs some kludgy > IPv4 alternative. The question is going to be how far can we > stretch the IPv4 that we have. > > It's been observed before on this list that most large networks > have very "loose" allocations. For example the standard customer > static IPv4 allocation is a /29 and a /30 on a point-to-point link to > that customer. In reality it could be a /30 and unnumbered on the > point-to-point link since it's almost a given that all of > the customers getting /29's are only using a single number. > And if you want to force the end user to use a /32 you can > run PPP right to their router. > > I think most established ISP's are aware of this and figure they can > self-generate IPv4 for 3-5 years post-runout. Their feeling is > why should I kill myself trying to kick my peers asses > to get them running IPv6 natively, when I can do nothing and allow > all the deep-pocket startup ISP's out there who are flush with > VC funding and have no IPv4 stored up, to beat my peers for me. Then > once my peers are IPv6 native, I'll just switch it on and be gold. > It kind of sucks for the new guy on the block, but that is also > a normal characteristic of established markets. > > Ted > From marty at akamai.com Mon Jan 18 10:14:56 2010 From: marty at akamai.com (Martin Hannigan) Date: Mon, 18 Jan 2010 10:14:56 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> Message-ID: On Jan 18, 2010, at 9:37 AM, Davis, Terry L wrote: > Martin > > We are fine. 6 or 7 years back we got ours. > > For small companies, start ups, or lab use, even fees of this scale > is often a make or break. We grew our IP infrastructure out of our > labs. It would have taken off much slower here if a few of us > couldn't have simply emailed in to request public IPv4 class C's for > our lab environments; it would have been hard to justify paying for > addresses back then. > > Take care > Terry > > > Terry, The fee issue is a Red Herring. Smallest V4 Allocation Fee: $1250.00 /21 or longer (2048 unique addresses) Smallest V6 Allocation Fee: $1250.00 /48 or longer (154.7425049 septillion addresses) Section 11 of the NRPM also defines experimental allocations for both v4 and v6 and there is a fee schedule supporting it. Best, Martin [ clip ] > > Interesting. Here is the fee schedule, Terry: > > > > X-small $1,250 /48 to /41 > > Small $2,250 /40 to /32 > > Medium $4,500 /31 to /30 > > Large $9,000 /29 to /27 > > X-large $18,000 /26 to /22 > > XX-large $36,000 Larger than /22 > > > > Which one is too expensive for your actual needs? > > > > > > -M< > From notdoctorx at yahoo.ca Mon Jan 18 11:21:50 2010 From: notdoctorx at yahoo.ca (Not Doctor X) Date: Mon, 18 Jan 2010 08:21:50 -0800 (PST) Subject: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review In-Reply-To: References: <921874.2184.qm@web113912.mail.gq1.yahoo.com> <5F4D6170-5773-4A35-A9E8-1EC887050042@arin.net> <788174.73831.qm@web113919.mail.gq1.yahoo.com> Message-ID: <306615.4959.qm@web113917.mail.gq1.yahoo.com> John you are correct. Now that you have explained this too me you are right. I owe you and the members an apology and will draft one to that end. My only excuse is that when I received your message I didn't understand it. I agreed with it. But I misinterpreted it. A bit like the F/U ruckus we had earlier. I apologize to you personally John for the misunderstanding. kindest regards joe baptista ________________________________ From: John Curran To: Not Doctor X ; Joe Baptista Cc: arin ppml Sent: Sun, January 17, 2010 9:56:02 AM Subject: Re: [arin-ppml] Mail postings from Joe Baptista held pending AUP Committee review On Jan 17, 2010, at 9:24 AM, Not Doctor X wrote: >John: > >Thank you for your clarification concerning ARIN policy at the AUP. As a judicial or administrative process it merits the classification status of "star chamber" which see reference: http://bit.ly/7j7UZu > >As you have confirmed John the AUP Committee may act in secret "and no notice is required before or after". This is unacceptable with respect to the allegations against me made here by you. Being that I have in some way caused the disruption of civil order and decorum on the mailing lists. > >Kindly ask the star chamber to detail what it is I have done that violated the AUP and I will apologist and promise never to do it again. But please don't keep my offense a secret. I demand the decision of the AUP concerning me be made public for all to see and admire and to assist me in making a proper signed apology. In other words I put you to the strict proof thereof. > >I also remind the star committee that it is I who has been libeled, slandered and defamed on an ARIN mailing list. And now I have been silenced? I think thats a bad omen and the action taken may be considered defamatory. I ask that the committee kindly consider that they may be contributing to further defamation of my character by their current actions. > >Furthermore I apologize for posting to the list when it is clear now to me that I should not have posted. I hold John Curran and the AUP Committee responsible for my actions in this. It is impossible to follow rules or rulings when they are kept secret from the person whom the ruling applies to. This has always been a problem with star chambers and secrecy. > >kindest regards >joe baptista > Joe - The AUP Committee performs the single focused administrative role of providing oversight to the staff process of AUP administration and is made up of both representatives of two elected bodies (Board of Trustees & ARIN Advisory Council) as well as one member appointed at large. It is not a judicial body in any sense; such remain available to you (and ARIN) if they prove necessary. On January 9th, you were informed specifically that your messages regarding Chris Mettin/GQHS were off-topic for the PPML list (see attached). Since that warning, you have repeatedly posted additional emails on that topic and unrelated to the Internet number resource policy. The ARIN Mailing Lists serve as a forum for particular subject matter and must remain focused on those topics to be useful to the community. The lists do not serve as your personal forum; please take your posts not directly related to number resource policy elsewhere. As noted, if you wish to correspond with the committee, you may contact the Chair or send email to the "aupabuse at arin.net" email address which will also reach them. Thank you, /John John Curran President and CEO ARIN === Begin forwarded message: From: John Curran > >Date: January 9, 2010 9:12:49 PM EST > >To: Joe Baptista > >Cc: arin ppml > >Subject: Re: [arin-ppml] Christopher Mettin > > >On Jan 8, 2010, at 8:36 AM, Joe Baptista wrote: > >John: >> >>First a belated thank you for the update from the AUP committee on Christopher Mettin the representative of the Gymnasium Querfurt High School. >> >>I have recently sent a formal notice to Christopher's principle Dr. Daumer demanding an apology for Christopher's defamatory comments against myself in which I requested a further apology be made by the school to the members here. >> >>FYI the letter in PDF can be seen at the following URL >> >>http://bit.ly/6q0r2g >> >>kindest regards >>joe baptista > >Joe - > > >To the extent that you consider it your duty to keep the community informed in this matter, please consider that duty fully discharged at this point. > > >It would be best if all would refrain from further email on this topic on the PPML list, as it is not relevant to the formation of public number resource policy. > > >Thanks! >/John > > >John Curran >President and CEO >ARIN > >= _______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. > __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Jan 18 11:50:14 2010 From: bill at herrin.us (William Herrin) Date: Mon, 18 Jan 2010 11:50:14 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <973D0AE1-738A-4E65-B359-E022CE792D71@delong.com> References: <4B4FA35F.9070804@arin.net> <30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <32154.1263688132@marajade.sandelman.ca> <3c3e3fca1001170746n3a2bc600q79267170522aaf7b@mail.gmail.com> <973D0AE1-738A-4E65-B359-E022CE792D71@delong.com> Message-ID: <3c3e3fca1001180850l19b567cfs75bc849cf8ce8074@mail.gmail.com> On Sun, Jan 17, 2010 at 9:27 PM, Owen DeLong wrote: > Even if this is true (I'm not completely convinced), you're comparing > ULA at 1:100 Falls Church, VA 22042-3004 From bill at herrin.us Mon Jan 18 11:52:44 2010 From: bill at herrin.us (William Herrin) Date: Mon, 18 Jan 2010 11:52:44 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <11434.1263779700@marajade.sandelman.ca> References: <4B4FA35F.9070804@arin.net> <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> <4B53511E.8010103@umn.edu> <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> <11434.1263779700@marajade.sandelman.ca> Message-ID: <3c3e3fca1001180852v7ab9cb9h531fda6b182e689e@mail.gmail.com> On Sun, Jan 17, 2010 at 8:55 PM, Michael Richardson wrote: > ? ?William> 7. Registration is non-binding. ARIN guarantees only that if both > ? ?William> networks participate in registration then they won't have > ? ?William> conflicting address use. > > ?I'm not sure I get what non-binding means here. Hi Michael, Non-binding in the sense that you're not required to participate in the registry in order to select and use ULA addresses. Registration is advantageous and it offers COINs a simple way to resolve conflicts, but it's not required. > ? ?William> The $10 supports operating a heavily automated registry. > ? ?William> The $1 provides mild back-pressure against wasteful > ? ?William> consumption of /48's. > > ?However, realize that we basically can never get these addresses back. > My position might be... if you stop paying the fee, then the > registration information that was previously private, becomes public. Nah, just flush the registration info and put them in a hold-pool where you don't reassign them until explicitly requested by someone or needed to meet some other policy requirement. > ? ?William> The contiguity requirement mildly encourages smart > ? ?William> aggregation practices. > > ?I do not know why this is important. > > ?These are networks that can never appear in the DFZ. > ?They may appear in various COINs, VPNs, enterprises, or personal-area > networks. > ?64K subnets is enough for many, and anyone with that many routes (a > COIN or VPN with 256 sites of 256 subnets...) won't be very worried that > their second /48 does not aggregate with their first /48, I think. Aggregation is valuable in any modestly complex network and the back-pressure here is very mild. If you want to register a disaggregate /48, you just create another $10 account. On Sun, Jan 17, 2010 at 9:49 PM, Owen DeLong wrote: > On Jan 17, 2010, at 3:50 PM, William Herrin wrote: >> 1. Ask IANA for a /16 delegation of of the existing ULA space, e.g. >> FC42::/16.Failing that, simply assert regiistration over a portion of >> ULA space e.g. FD42::/16. >> > Personally, I would rather see us move in the direction of making no > distinction between numbers for connected and disconnected networks. > Unless you want to put ARIN in the role of gatekeeper to the routing > table (which I think is a bad idea), there's no need for such a distinction. Hi Owen, I agree in principle, but recognize that no form of needs-based allocation is likely to be acceptable for private addressing. So long as we maintain a needs-basis for the public address pools, a uniform policy is unlikely to be helpful for non-connected users. > Should there be inter-RIR cooperation on this such that if you participate > in ARIN registration, you're not going to conflict with APNIC registrants? > If so, this probably requires a global or globally coordinated proposal. No significant coordination is needed. ARIN would only manage registration for a small subset of the ULA space. To the extent that other RIRs want to do something similar, they need only avoid the particular /16 that ARIN manages. > This pricing strategy, while interesting, isn't particularly relevant to > a policy discussion. If you want to talk about fees ARIN should > charge, I believe it is better suited to the arin-discuss list. Respectfully, everything that impacts the eventual implementation of a policy is relevant to the policy discussion, even those elements which do not belong in the policy document itself. Also, arin-discuss is a closed list while this is a public discussion. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jhg at omsys.com Mon Jan 18 15:17:17 2010 From: jhg at omsys.com (Jeremy H. Griffith) Date: Mon, 18 Jan 2010 12:17:17 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> Message-ID: On Mon, 18 Jan 2010 10:14:56 -0500, Martin Hannigan wrote: >The fee issue is a Red Herring. > >Smallest V4 Allocation Fee: $1250.00 /21 or longer (2048 unique >addresses) >Smallest V6 Allocation Fee: $1250.00 /48 or longer (154.7425049 >septillion addresses) > >Section 11 of the NRPM also defines experimental allocations for both >v4 and v6 and there is a fee schedule supporting it. It must be really nice to work for a company where a mere $1250 doesn't matter. Sure wish I did. Around here, anything over $99 is most unlikely to be approved, especially in the last year. Or maybe you live on another planet? --JHG From bicknell at ufp.org Mon Jan 18 16:08:31 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Jan 2010 13:08:31 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <20100118210831.GA74082@ussenterprise.ufp.org> In a message written on Mon, Jan 18, 2010 at 12:17:17PM -0800, Jeremy H. Griffith wrote: > On Mon, 18 Jan 2010 10:14:56 -0500, Martin Hannigan > wrote: > >The fee issue is a Red Herring. > > > >Smallest V4 Allocation Fee: $1250.00 /21 or longer (2048 unique > >addresses) > >Smallest V6 Allocation Fee: $1250.00 /48 or longer (154.7425049 > >septillion addresses) > > > >Section 11 of the NRPM also defines experimental allocations for both > >v4 and v6 and there is a fee schedule supporting it. > > It must be really nice to work for a company where > a mere $1250 doesn't matter. Sure wish I did. > Around here, anything over $99 is most unlikely to > be approved, especially in the last year. Or maybe > you live on another planet? From https://www.arin.net/fees/fee_schedule.html: IPv4 and IPv6 Allocation Annual Subscription Renewal Organizations issued or transferred both IPv4 and IPv6 allocations by ARIN under a single Org ID pay the larger of the two annual renewal fees. I think ARIN should make this bold, blink, and bright red, at least until the page can be rewritten so this is much more clear. t=0: Pay $1250 "initial allocation" for an IPv4 /21. t=1: Pay $1250 "renewal" for an IPv4 /21. t=2: Pay $1250 "renewal" for an IPv4 /21. Pay $0 for an IPv6 /48. "ARIN charges a fee for the initial IPv6 allocation from ARIN to an ISP. This fee is currently waived for IPv4 subscribers. For organizations that aren't IPv4 subscribers, the fee is lowered by current fee waivers." t=3: Pay $1250, the max of: $1250 for the IPv4 renewal $1250 for the IPv6 renewal "Organizations issued or transferred both IPv4 and IPv6 allocations by ARIN under a single Org ID pay the larger of the two annual renewal fees." Now, let's compare with the cost of just doing IPv4, which would be $1250 per year. Humm, let's see, it costs $0 more to get IPv6 address space (right now). So, let's try this again. Will your manager approve $0? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From owen at delong.com Mon Jan 18 16:19:51 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Jan 2010 13:19:51 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100118210831.GA74082@ussenterprise.ufp.org> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> Message-ID: On Jan 18, 2010, at 1:08 PM, Leo Bicknell wrote: > In a message written on Mon, Jan 18, 2010 at 12:17:17PM -0800, Jeremy H. Griffith wrote: >> On Mon, 18 Jan 2010 10:14:56 -0500, Martin Hannigan >> wrote: >>> The fee issue is a Red Herring. >>> >>> Smallest V4 Allocation Fee: $1250.00 /21 or longer (2048 unique >>> addresses) >>> Smallest V6 Allocation Fee: $1250.00 /48 or longer (154.7425049 >>> septillion addresses) >>> >>> Section 11 of the NRPM also defines experimental allocations for both >>> v4 and v6 and there is a fee schedule supporting it. >> >> It must be really nice to work for a company where >> a mere $1250 doesn't matter. Sure wish I did. >> Around here, anything over $99 is most unlikely to >> be approved, especially in the last year. Or maybe >> you live on another planet? > > From https://www.arin.net/fees/fee_schedule.html: > > IPv4 and IPv6 Allocation Annual Subscription Renewal > > Organizations issued or transferred both IPv4 and IPv6 allocations by > ARIN under a single Org ID pay the larger of the two annual renewal > fees. > > I think ARIN should make this bold, blink, and bright red, at least > until the page can be rewritten so this is much more clear. > > t=0: Pay $1250 "initial allocation" for an IPv4 /21. > > t=1: Pay $1250 "renewal" for an IPv4 /21. > > t=2: Pay $1250 "renewal" for an IPv4 /21. > Pay $0 for an IPv6 /48. > Um, anyone who would be paying $1250 renewal for an IPv4 /21 is not eligible to get an IPv6 /48 under current policy. They would get an IPv6 /32. > "ARIN charges a fee for the initial IPv6 allocation from ARIN to an ISP. > This fee is currently waived for IPv4 subscribers. For organizations > that aren't IPv4 subscribers, the fee is lowered by current fee waivers." > > t=3: Pay $1250, the max of: > $1250 for the IPv4 renewal > $1250 for the IPv6 renewal > > "Organizations issued or transferred both IPv4 and IPv6 allocations by > ARIN under a single Org ID pay the larger of the two annual renewal > fees." > Just to be clear: This timeline and pricing applies to ISPs. The same timeline for end users looks like this: t=0: Pay $500 "ASN assignment" t=0: Pay $1250 "initial assignment" for an IPv4 /22 t=1: Pay $100 "renewal" for an IPv4 /22 and an ASN t=2: Pay $1250 "initial assignment" for an IPv6 /48 t=3: pay $100 renewal for an IPv4 /22, an IPv6 /48 and an ASN > Now, let's compare with the cost of just doing IPv4, which would > be $1250 per year. Humm, let's see, it costs $0 more to get IPv6 > address space (right now). > > So, let's try this again. Will your manager approve $0? > So, let's try this again, since the person in question was talking about an enterprise network... It's $1250 more, ONCE to get that IPv6. There was a time when there was a discount on the initial assignments of IPv6 space. I got my /48 for $500 early in that process. Personally, I'm in favor of bringing back the assignment discounts, but, that really is an arin-discuss topic and not a PPML topic. Owen From bicknell at ufp.org Mon Jan 18 16:30:17 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Jan 2010 13:30:17 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> Message-ID: <20100118213017.GA76031@ussenterprise.ufp.org> In a message written on Mon, Jan 18, 2010 at 01:19:51PM -0800, Owen DeLong wrote: > The same timeline for end users looks like this: > > t=0: Pay $500 "ASN assignment" > t=0: Pay $1250 "initial assignment" for an IPv4 /22 > t=1: Pay $100 "renewal" for an IPv4 /22 and an ASN > t=2: Pay $1250 "initial assignment" for an IPv6 /48 https://www.arin.net/fees/fee_schedule.html, very bottom, fee wavers. In 2010 this is $625. It was $312.50 last year, it will be $937.50 next year. It was $0 in 2007 (full waver) and it was $125 in 2008. Based on the original post it would have been a maximum of 312.50, since the request happened in the past. It might have been less, depending on how far in the past. > t=3: pay $100 renewal for an IPv4 /22, an IPv6 /48 and an ASN > So, let's try this again, since the person in question was talking about > an enterprise network... It's $1250 more, ONCE to get that IPv6. > There was a time when there was a discount on the initial assignments > of IPv6 space. I got my /48 for $500 early in that process. I think the real moral of this story is the ARIN fee schdule page is about as clear as mud. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From matthew at matthew.at Mon Jan 18 16:20:08 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 18 Jan 2010 13:20:08 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100118210831.GA74082@ussenterprise.ufp.org> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> Message-ID: <4B54D088.4060505@matthew.at> Leo Bicknell wrote: > > > t=0: Pay $1250 "initial allocation" for an IPv4 /21. > t=0: Pay absolutely nothing for my legacy IPv4 space > t=1: Pay $1250 "renewal" for an IPv4 /21. > t=1: Continue to pay absolutely nothing for my legacy IPv4 space > t=2: Pay $1250 "renewal" for an IPv4 /21. > Pay $0 for an IPv6 /48. > t=2: Continue to pay absolutely nothing for my legacy IPv4 space, don't get any IPv6 space because I can't afford to pay the $1250 for PI IPv6 space for the project. > > > t=3: Pay $1250, the max of: > $1250 for the IPv4 renewal > $1250 for the IPv6 renewal > t=3: Continue to pay absolutely nothing for my legacy IPv4 space, continue to not experiment with IPv6 because I still can't pay the $1250 for the PI IPv6 space. t=n: Sell enough of my legacy IPv4 space in a transfer market that I can establish an ongoing account for my IPv6 space fees Matthew Kaufman From owen at delong.com Mon Jan 18 16:56:47 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Jan 2010 13:56:47 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B54D088.4060505@matthew.at> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <4B54D088.4060505@matthew.at> Message-ID: <23EBD956-14CD-4F57-9027-9A3257B7F2F3@delong.com> On Jan 18, 2010, at 1:20 PM, Matthew Kaufman wrote: > Leo Bicknell wrote: >> >> >> t=0: Pay $1250 "initial allocation" for an IPv4 /21. >> > t=0: Pay absolutely nothing for my legacy IPv4 space >> t=1: Pay $1250 "renewal" for an IPv4 /21. >> > t=1: Continue to pay absolutely nothing for my legacy IPv4 space >> t=2: Pay $1250 "renewal" for an IPv4 /21. >> Pay $0 for an IPv6 /48. >> > t=2: Continue to pay absolutely nothing for my legacy IPv4 space, don't get any IPv6 space because I can't afford to pay the $1250 for PI IPv6 space for the project. >> >> >> t=3: Pay $1250, the max of: >> $1250 for the IPv4 renewal >> $1250 for the IPv6 renewal >> > t=3: Continue to pay absolutely nothing for my legacy IPv4 space, continue to not experiment with IPv6 because I still can't pay the $1250 for the PI IPv6 space. > > t=n: Sell enough of my legacy IPv4 space in a transfer market that I can establish an ongoing account for my IPv6 space fees > I wish you the best of luck with that. The risk side of that equation, of course, is: t=n: The internet has passed me by and my business became irrelevant to the world since IPv6-only customers thought I went out of business when they couldn't find my web site. Owen From matthew at matthew.at Mon Jan 18 17:11:10 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 18 Jan 2010 14:11:10 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <23EBD956-14CD-4F57-9027-9A3257B7F2F3@delong.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <4B54D088.4060505@matthew.at> <23EBD956-14CD-4F57-9027-9A3257B7F2F3@delong.com> Message-ID: <4B54DC7E.40203@matthew.at> Owen DeLong wrote: > > t=n: The internet has passed me by and my business became irrelevant to the world since IPv6-only customers > thought I went out of business when they couldn't find my web site. > > This is for the part of the Internet that isn't just web sites. But otherwise, you'd have a great point. Matthew Kaufman From mysidia at gmail.com Mon Jan 18 19:32:12 2010 From: mysidia at gmail.com (James Hess) Date: Mon, 18 Jan 2010 18:32:12 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100118210831.GA74082@ussenterprise.ufp.org> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> Message-ID: <6eb799ab1001181632u83ae0b3nc688ff941a00b666@mail.gmail.com> On Mon, Jan 18, 2010 at 3:08 PM, Leo Bicknell wrote: [snip] > t=0: Pay $1250 "initial allocation" for an IPv4 /21. > t=1: Pay $1250 "renewal" for an IPv4 /21. If you received an additional /21 between t=0 and t=1, sure. The fee schedule currently indicates 'renewal' is only incurred for resources actually issued or transferred during that year: https://www.arin.net/fees/fee_schedule.html#annual_fees "This annual fee covers all resources issued or transferred to the Org ID by ARIN. [...] The annual renewal fee is based on the rate at which IPv4 addresses are allocated to the Org ID, and not on the aggregate number of IPv4 addresses held by the Org ID." So based on this: t=1 Pay no renewal, since no resources transferred or issued t=2 Pay $0 "renewal" Pay $1250 for IPv6 /48, since it is the greater of the two amounts. So you see.. it is indicative of a disincentive to adopt V6. The IPv4 user wanting an initial IPv6 allocation incurs a substantially large expense... -- -J From mcr at sandelman.ca Mon Jan 18 18:20:48 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 18 Jan 2010 18:20:48 -0500 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria In-Reply-To: <3c3e3fca1001180852v7ab9cb9h531fda6b182e689e@mail.gmail.com> References: <4B4FA35F.9070804@arin.net> <3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com> <4B53511E.8010103@umn.edu> <3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com> <11434.1263779700@marajade.sandelman.ca> <3c3e3fca1001180852v7ab9cb9h531fda6b182e689e@mail.gmail.com> Message-ID: <5459.1263856848@marajade.sandelman.ca> >>>>> "William" == William Herrin writes: >> ? ?William> The $10 supports operating a heavily automated registry. >> ? ?William> The $1 provides mild back-pressure against wasteful >> ? ?William> consumption of /48's. >> >> ?However, realize that we basically can never get these addresses back. >> My position might be... if you stop paying the fee, then the >> registration information that was previously private, becomes public. William> Nah, just flush the registration info and put them in a hold-pool William> where you don't reassign them until explicitly requested by William> someone or William> needed to meet some other policy requirement. Okay, so in IPv6, that's pretty much never. >> ?They may appear in various COINs, VPNs, enterprises, or personal-area >> networks. >> ?64K subnets is enough for many, and anyone with that many routes (a >> COIN or VPN with 256 sites of 256 subnets...) won't be very worried that >> their second /48 does not aggregate with their first /48, I think. William> Aggregation is valuable in any modestly complex network and the William> back-pressure here is very mild. If you want to register a William> disaggregate /48, you just create another $10 account. I'd rather just give you the /44 to anyone who pays $20 then, as with your prop103, rather than reserve things for "later". William> I agree in principle, but recognize that no form of needs-based William> allocation is likely to be acceptable for private William> addressing. So long as we maintain a needs-basis for the William> public address pools, a uniform William> policy is unlikely to be helpful for non-connected users. +1 -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Mon Jan 18 18:01:20 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 18 Jan 2010 18:01:20 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <8FF49FA5103C8D4DB1933ECE41EB477F04823522@HOUEXCH01.PLANET.LOCAL> References: <4B4FA35F.9070804@arin.net><30072.1263585278@marajade.sandelman.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <8FF49FA5103C8D4DB1933ECE41EB477F04823521@HOUEXCH01.PLANET.LOCAL> <32402.1263688306@marajade.sandelman.ca> <8FF49FA5103C8D4DB1933ECE41EB477F04823522@HOUEXCH01.PLANET.LOCAL> Message-ID: <4285.1263855680@marajade.sandelman.ca> >>>>> "Stan" == Stan Barber writes: Stan> Terry, NTT has a large v6 deployment to the home in Japan Stan> called Hakari-TV. This is a walled-garden deployment for VOD Stan> (and other related features) to the home. mcr> By "walled garden", do you mean that the address space is not mcr> globally routed? Stan> Yes, that's what I understand to be the case. Okay, so what address space did they use? Did they use ULA? If not, why not? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From gbonser at seven.com Mon Jan 18 21:24:30 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 18 Jan 2010 18:24:30 -0800 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignmentcriteria In-Reply-To: <5459.1263856848@marajade.sandelman.ca> References: <4B4FA35F.9070804@arin.net><3c3e3fca1001170840m314c746che6215d86e459b4e5@mail.gmail.com><4B53511E.8010103@umn.edu><3c3e3fca1001171550j30e056c3u8300c4f48fe754ad@mail.gmail.com><11434.1263779700@marajade.sandelman.ca><3c3e3fca1001180852v7ab9cb9h531fda6b182e689e@mail.gmail.com> <5459.1263856848@marajade.sandelman.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72CF@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net On > Behalf Of Michael Richardson > Sent: Monday, January 18, 2010 3:21 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 107: Rework of IPv6 > assignmentcriteria > > > > I'd rather just give you the /44 to anyone who pays $20 then, as with > your prop103, rather than reserve things for "later". I second that sentiment. Having to go back to ARIN for each /48 as you need them is a pain in the hips for the operator and ARIN. From joelja at bogus.com Mon Jan 18 16:06:04 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Jan 2010 13:06:04 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4B54CD3C.6020403@bogus.com> Jeremy H. Griffith wrote: >> Smallest V4 Allocation Fee: $1250.00 /21 or longer (2048 unique >> addresses) >> Smallest V6 Allocation Fee: $1250.00 /48 or longer (154.7425049 >> septillion addresses) >> >> Section 11 of the NRPM also defines experimental allocations for both >> v4 and v6 and there is a fee schedule supporting it. > > It must be really nice to work for a company where > a mere $1250 doesn't matter. Sure wish I did. > Around here, anything over $99 is most unlikely to > be approved, especially in the last year. Or maybe > you live on another planet? As with any business expenditure, opportunity needs to to balanaced against cost. there are plenty of organizations who don't view this as especially onerous. It is possible that it excludes users who might otherwise meet the criterion but it's not that high a barrier to entry. If it is also high enough to discriminate against some kinds of abuse how bad a consequence is that? joel > --JHG From marty at akamai.com Tue Jan 19 14:22:51 2010 From: marty at akamai.com (Martin Hannigan) Date: Tue, 19 Jan 2010 14:22:51 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <2F6DBEDA-AA90-4150-ACAF-A2684C884B09@akamai.com> On Jan 18, 2010, at 3:17 PM, Jeremy H. Griffith wrote: > On Mon, 18 Jan 2010 10:14:56 -0500, Martin Hannigan > wrote: > > >The fee issue is a Red Herring. > > > >Smallest V4 Allocation Fee: $1250.00 /21 or longer (2048 unique > >addresses) > >Smallest V6 Allocation Fee: $1250.00 /48 or longer (154.7425049 > >septillion addresses) > > > >Section 11 of the NRPM also defines experimental allocations for both > >v4 and v6 and there is a fee schedule supporting it. > > It must be really nice to work for a company where > a mere $1250 doesn't matter. Sure wish I did. > Around here, anything over $99 is most unlikely to > be approved, especially in the last year. Or maybe > you live on another planet? > > --JHG > [ Thanks, Leo, for expanding ] A large part of my function is dealing with costs and I don't differentiate size. I don't consider it a mere $1250, I consider it as "currently acceptable" as a cost of doing business based on how ARIN funds itself (through these fees) and what they have reported back to us in the yearly financial report. How exactly are these costs impacting you outside of being bundled with your transit cost? Best, -M< From mcr at sandelman.ca Tue Jan 19 15:02:41 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 19 Jan 2010 15:02:41 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100118210831.GA74082@ussenterprise.ufp.org> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> Message-ID: <14568.1263931361@marajade.sandelman.ca> >>>>> "Leo" == Leo Bicknell writes: Leo> "ARIN charges a fee for the initial IPv6 allocation from Leo> ARIN to an ISP. This fee is currently waived for IPv4 Leo> subscribers. For organizations that aren't IPv4 subscribers, Leo> the fee is lowered by current fee waivers." Leo> t=3: Pay $1250, the max of: $1250 for the IPv4 renewal $1250 Leo> for the IPv6 renewal Leo> "Organizations issued or transferred both IPv4 and IPv6 Leo> allocations by ARIN under a single Org ID pay the larger of the Leo> two annual renewal fees." Leo> Now, let's compare with the cost of just doing IPv4, which Leo> would be $1250 per year. Humm, let's see, it costs $0 more to Leo> get IPv6 address space (right now). Leo> So, let's try this again. Will your manager approve $0? Cost of 10.0.0.0/24 = $0. Cost of IPv6, > $0. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Tue Jan 19 15:09:29 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Jan 2010 12:09:29 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <14568.1263931361@marajade.sandelman.ca> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> Message-ID: <0FDF09C5-F8FB-4269-B9D0-757107C6A78F@delong.com> On Jan 19, 2010, at 12:02 PM, Michael Richardson wrote: > >>>>>> "Leo" == Leo Bicknell writes: > Leo> "ARIN charges a fee for the initial IPv6 allocation from > Leo> ARIN to an ISP. This fee is currently waived for IPv4 > Leo> subscribers. For organizations that aren't IPv4 subscribers, > Leo> the fee is lowered by current fee waivers." > > Leo> t=3: Pay $1250, the max of: $1250 for the IPv4 renewal $1250 > Leo> for the IPv6 renewal > > Leo> "Organizations issued or transferred both IPv4 and IPv6 > Leo> allocations by ARIN under a single Org ID pay the larger of the > Leo> two annual renewal fees." > > Leo> Now, let's compare with the cost of just doing IPv4, which > Leo> would be $1250 per year. Humm, let's see, it costs $0 more to > Leo> get IPv6 address space (right now). > > Leo> So, let's try this again. Will your manager approve $0? > > Cost of 10.0.0.0/24 = $0. > Cost of IPv6, > $0. > Cost of IPv6 ULA = $0, same as IPv4 RFC-1918. Cost of routable IPv4 /22 = $1250, Cost of IPv6 routable /48 = $1250. Let's try to do apples to apples comparisons. Owen From gbonser at seven.com Tue Jan 19 15:37:47 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 12:37:47 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <14568.1263931361@marajade.sandelman.ca> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> > Leo> So, let's try this again. Will your manager approve $0? > > Cost of 10.0.0.0/24 = $0. > Cost of IPv6, > $0. As an end user, I recently (mistakenly) asked for and received a /48 (should have been larger). > Amount owed for this approval: $1250 It cost us $1250 notwithstanding the fact we already have a /21 IPv4 assignment I had to get justification for that spending. There was some pushback in some areas and it went something like this: Q: Why do we need this? A: IPv4 addresses are running out and we are growing. Some of our partners/peers are IPv6 capable. Q: I have been hearing that for the past 10 years. A: Yes but it really, really, really, is this time. Then we get a /48 which we got based on a lack of understanding of IPv6 practices (we thought IPv6 practice was a /56 per site and not a /48 per site) which led to I need to go back and get more address space, I don't know if it is going to cost us more or not. Q: We are growing fairly rapidly, is ARIN going to nickel and dime us to death with requiring us to keep coming back for more of these? A: Probably. They seem pretty tight-fisted on address allocation, still, but there is some policy discussion aimed at simplifying that and allowing larger initial block assignments. Turns out in subsequent discussion with ARIN that I will be able to get a /45 (asked for a /44 but a /45 meets my needs so that is what they will give me) as I believe a /45 is still a "small" allocation, I think I can simply have the /48 upgraded to a /45 and not pay the fee again as the initial /48 was never placed into service. From owen at delong.com Tue Jan 19 15:47:14 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Jan 2010 12:47:14 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> Message-ID: <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> On Jan 19, 2010, at 12:37 PM, George Bonser wrote: >> Leo> So, let's try this again. Will your manager approve $0? >> >> Cost of 10.0.0.0/24 = $0. >> Cost of IPv6, > $0. > > > As an end user, I recently (mistakenly) asked for and received a /48 > (should have been larger). > >> Amount owed for this approval: $1250 > > It cost us $1250 notwithstanding the fact we already have a /21 IPv4 > assignment > > I had to get justification for that spending. There was some pushback > in some areas and it went something like this: > > Q: Why do we need this? > A: IPv4 addresses are running out and we are growing. Some of our > partners/peers are IPv6 capable. > Q: I have been hearing that for the past 10 years. > A: Yes but it really, really, really, is this time. > > Then we get a /48 which we got based on a lack of understanding of IPv6 > practices (we thought IPv6 practice was a /56 per site and not a /48 per > site) which led to > > I need to go back and get more address space, I don't know if it is > going to cost us more or not. > > Q: We are growing fairly rapidly, is ARIN going to nickel and dime us to > death with requiring us to keep coming back for more of these? > A: Probably. They seem pretty tight-fisted on address allocation, > still, but there is some policy discussion aimed at simplifying that and > allowing larger initial block assignments. > That certainly isn't the intent. ARIN policy for IPv6 is intended to allow you to apply for that address space you can reasonably justify. If you don't need more than 256 subnets per site, then, there is nothing wrong with assigning a /56 per site. However, if you think you might, then, a /48 per site is prudent. > Turns out in subsequent discussion with ARIN that I will be able to get > a /45 (asked for a /44 but a /45 meets my needs so that is what they > will give me) as I believe a /45 is still a "small" allocation, I think > I can simply have the /48 upgraded to a /45 and not pay the fee again as > the initial /48 was never placed into service. > I'm surprised they won't give you the /44. We're working on policy to fix that. All of the IPv6 policies under consideration for the next meeting do rectify this and cause ARIN to allocate IPv6 on nibble boundaries (or more). Owen From gbonser at seven.com Tue Jan 19 16:15:35 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 13:15:35 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> > That certainly isn't the intent. ARIN policy for IPv6 is intended to > allow you to > apply for that address space you can reasonably justify. > > If you don't need more than 256 subnets per site, then, there is > nothing wrong > with assigning a /56 per site. However, if you think you might, then, > a /48 per > site is prudent. The problem is, being multihomed, nobody is going to take a /56 announcement for a site and while we do have our sites in the SF Bay area interconnected and our policy is to announce an aggregate route, we have upstream transit and peering at the individual sites and if anything should happen to the backhaul between the sites we would need to deaggregate the announcement. Most will take a /48 announcement from PI space, practically nobody (aside from the immediate upstream) would take a /56. We played with the notion of being able to announce a /56 if all sites had access to the same upstreams and having them aggregate it to their peers but realized that the current "best practice" is to simply announce a /48 or better. And we plan of expansion outside of the area that are likely going to be discrete networks so again, a /48 is the only thing that is going to work. > > I'm surprised they won't give you the /44. We're working on policy to > fix that. > All of the IPv6 policies under consideration for the next meeting do > rectify > this and cause ARIN to allocate IPv6 on nibble boundaries (or more). > > Owen I suppose they can only go by their current policy guidelines and apparently it is policy to allocate only what is needed for the immediate foreseeable future. George From owen at delong.com Tue Jan 19 16:32:01 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Jan 2010 13:32:01 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> Message-ID: <82601483-B685-41C3-95FE-060945AB46CB@delong.com> On Jan 19, 2010, at 1:15 PM, George Bonser wrote: >> That certainly isn't the intent. ARIN policy for IPv6 is intended to >> allow you to >> apply for that address space you can reasonably justify. >> >> If you don't need more than 256 subnets per site, then, there is >> nothing wrong >> with assigning a /56 per site. However, if you think you might, then, >> a /48 per >> site is prudent. > > The problem is, being multihomed, nobody is going to take a /56 > announcement for a site and while we do have our sites in the SF Bay > area interconnected and our policy is to announce an aggregate route, we > have upstream transit and peering at the individual sites and if > anything should happen to the backhaul between the sites we would need > to deaggregate the announcement. Most will take a /48 announcement from > PI space, practically nobody (aside from the immediate upstream) would > take a /56. We played with the notion of being able to announce a /56 > if all sites had access to the same upstreams and having them aggregate > it to their peers but realized that the current "best practice" is to > simply announce a /48 or better. > In that case, you should probably be applying under the Multiple Discreet Networks policy rather than getting an aggregate anyway. > And we plan of expansion outside of the area that are likely going to be > discrete networks so again, a /48 is the only thing that is going to > work. > > >> >> I'm surprised they won't give you the /44. We're working on policy to >> fix that. >> All of the IPv6 policies under consideration for the next meeting do >> rectify >> this and cause ARIN to allocate IPv6 on nibble boundaries (or more). >> >> Owen > > I suppose they can only go by their current policy guidelines and > apparently it is policy to allocate only what is needed for the > immediate foreseeable future. > The current policy is justified need. I think that is a stricter interpretation than is necessary, but, I don't know if that matters. Will we see you at the Toronto meeting? I hope you will participate and express your support for whatever changes you think are needed to IPv6 policy. Owen > George From gbonser at seven.com Tue Jan 19 16:54:59 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 13:54:59 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <82601483-B685-41C3-95FE-060945AB46CB@delong.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <82601483-B685-41C3-95FE-060945AB46CB@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72F2@RWC-EX1.corp.seven.com> > > > > I suppose they can only go by their current policy guidelines and > > apparently it is policy to allocate only what is needed for the > > immediate foreseeable future. > > > The current policy is justified need. I think that is a stricter > interpretation > than is necessary, but, I don't know if that matters. Will we see you > at the Toronto meeting? Huh? http://www.nanog.org/meetings/future/index.php When is Toronto? I will be lucky to make it to San Francisco and that is just up the road a piece. > I hope you will participate and express your > support for whatever changes you think are needed to IPv6 policy. I like prop106 from an end user's perspective. It certainly makes things simple. What is hard to gauge is address requirements having been living in the NAT world for so long and address conservation having been a major constraint on design. It is going to take a while to break out of that kind of thinking. From farmer at umn.edu Tue Jan 19 16:54:57 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Jan 2010 15:54:57 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> Message-ID: <4B562A31.2030406@umn.edu> George Bonser wrote: > The problem is, being multihomed, nobody is going to take a /56 > announcement for a site and while we do have our sites in the SF Bay > area interconnected and our policy is to announce an aggregate route, we > have upstream transit and peering at the individual sites and if > anything should happen to the backhaul between the sites we would need > to deaggregate the announcement. Most will take a /48 announcement from > PI space, practically nobody (aside from the immediate upstream) would > take a /56. We played with the notion of being able to announce a /56 > if all sites had access to the same upstreams and having them aggregate > it to their peers but realized that the current "best practice" is to > simply announce a /48 or better. > > And we plan of expansion outside of the area that are likely going to be > discrete networks so again, a /48 is the only thing that is going to > work. > > >> I'm surprised they won't give you the /44. We're working on policy to >> fix that. >> All of the IPv6 policies under consideration for the next meeting do >> rectify >> this and cause ARIN to allocate IPv6 on nibble boundaries (or more). >> >> Owen > > I suppose they can only go by their current policy guidelines and > apparently it is policy to allocate only what is needed for the > immediate foreseeable future. After reading this and a couple other posting, within PP#107 I want to make explicit that multiple sites are a justification for larger than a /48. However, I think some kind of qualification of multiple sites is necessary. I think two offices across town from each other with 10 host each and that share a common connection to the Internet probably shouldn't qualify for two /48s. I'm thinking of language something like this; "To qualify as a separate sites, locations must either be in separate cities and/or metropolitan areas, or if within the same city or metropolitan area to be considered separate sites each site must have independent connection to the Internet." So if you had two sites in different metro areas or two sites in the same metro area but each has a separate connection to the Internet then two /48s are justified. Is that reasonable? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Tue Jan 19 17:02:47 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Jan 2010 16:02:47 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72F2@RWC-EX1.corp.seven.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <82601483-B685-41C3-95FE-060945AB46CB@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72F2@RWC-EX1.corp.seven.com> Message-ID: <4B562C07.6050302@umn.edu> George Bonser wrote: >>> I suppose they can only go by their current policy guidelines and >>> apparently it is policy to allocate only what is needed for the >>> immediate foreseeable future. >>> >> The current policy is justified need. I think that is a stricter >> interpretation >> than is necessary, but, I don't know if that matters. Will we see you >> at the Toronto meeting? > > Huh? http://www.nanog.org/meetings/future/index.php > > When is Toronto? I will be lucky to make it to San Francisco and that > is just up the road a piece. This is not NANOG, it is ARIN, ARIN and NANOG do hold joint meeting is the fall, so maybe that confused you. See the following; https://www.arin.net/participate/meetings/index.html The next ARIN meeting is April 18-21 in Toronto, if you can't make the meeting, I suggest you try remote participation. I can't find the link for it right now, but it will be available when more of the details for the meeting get announced in a month or so. >> I hope you will participate and express your >> support for whatever changes you think are needed to IPv6 policy. > > I like prop106 from an end user's perspective. It certainly makes > things simple. What is hard to gauge is address requirements having > been living in the NAT world for so long and address conservation having > been a major constraint on design. It is going to take a while to break > out of that kind of thinking. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From scottleibrand at gmail.com Tue Jan 19 17:04:27 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 19 Jan 2010 14:04:27 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72F2@RWC-EX1.corp.seven.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <82601483-B685-41C3-95FE-060945AB46CB@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72F2@RWC-EX1.corp.seven.com> Message-ID: <4B562C6B.3050105@gmail.com> On 1/19/2010 1:54 PM, George Bonser wrote: >> Will we see you >> at the Toronto meeting? >> > Huh? http://www.nanog.org/meetings/future/index.php > > When is Toronto? I will be lucky to make it to San Francisco and that > is just up the road a piece. > https://www.arin.net/participate/meetings/ARIN-XXV/ The April meeting is not a back-to-back meeting with NANOG: that's just the fall one (Atlanta this year). Not sure if this applies to you, but if anyone, especially first-time participants, wants to attend an ARIN meeting but needs assistance to do so, check out https://www.arin.net/participate/meetings/fellowship.html -Scott From gbonser at seven.com Tue Jan 19 17:08:27 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 14:08:27 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B562C07.6050302@umn.edu> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <82601483-B685-41C3-95FE-060945AB46CB@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72F2@RWC-EX1.corp.seven.com> <4B562C07.6050302@umn.edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72F4@RWC-EX1.corp.seven.com> > > This is not NANOG, it is ARIN, ARIN and NANOG do hold joint meeting is > the fall, so maybe that confused you. See the following; > > https://www.arin.net/participate/meetings/index.html Heh, yeah, forgot which list I was reading, actually. > The next ARIN meeting is April 18-21 in Toronto, if you can't make the > meeting, I suggest you try remote participation. I can't find the link > for it right now, but it will be available when more of the details for > the meeting get announced in a month or so. I could participate remotely but am a single parent so it's difficult to get away. From gbonser at seven.com Tue Jan 19 17:37:37 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 14:37:37 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B562A31.2030406@umn.edu> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <4B562A31.2030406@umn.edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72F6@RWC-EX1.corp.seven.com> > However, I think some kind of qualification of multiple sites is > necessary. I think two offices across town from each other with 10 host > each and that share a common connection to the Internet probably > shouldn't qualify for two /48s. I'm thinking of language something > like > this; > > "To qualify as a separate sites, locations must either be in separate > cities and/or metropolitan areas, or if within the same city or > metropolitan area to be considered separate sites each site must have > independent connection to the Internet." > > So if you had two sites in different metro areas or two sites in the > same metro area but each has a separate connection to the Internet then > two /48s are justified. > > Is that reasonable? > Provided that you mean the separate connections are also to separate providers, yes. From tdurack at gmail.com Tue Jan 19 17:35:42 2010 From: tdurack at gmail.com (Tim Durack) Date: Tue, 19 Jan 2010 17:35:42 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> Message-ID: <9e246b4d1001191435q28bcfea5p91bb732361fd9c34@mail.gmail.com> On Tue, Jan 19, 2010 at 3:47 PM, Owen DeLong wrote: > > On Jan 19, 2010, at 12:37 PM, George Bonser wrote: > >>> ? ?Leo> So, let's try this again. ?Will your manager approve $0? >>> >>> Cost of 10.0.0.0/24 = $0. >>> Cost of IPv6, > $0. >> >> >> As an end user, I recently (mistakenly) asked for and received a /48 >> (should have been larger). >> >>> Amount owed for this approval: $1250 >> >> It cost us $1250 notwithstanding the fact we already have a /21 IPv4 >> assignment >> >> I had to get justification for that spending. ?There was some pushback >> in some areas and it went something like this: >> >> Q: Why do we need this? >> A: IPv4 addresses are running out and we are growing. Some of our >> partners/peers are IPv6 capable. >> Q: I have been hearing that for the past 10 years. >> A: Yes but it really, really, really, is this time. >> >> Then we get a /48 which we got based on a lack of understanding of IPv6 >> practices (we thought IPv6 practice was a /56 per site and not a /48 per >> site) which led to >> >> I need to go back and get more address space, I don't know if it is >> going to cost us more or not. >> >> Q: We are growing fairly rapidly, is ARIN going to nickel and dime us to >> death with requiring us to keep coming back for more of these? >> A: Probably. ?They seem pretty tight-fisted on address allocation, >> still, but there is some policy discussion aimed at simplifying that and >> allowing larger initial block assignments. >> > That certainly isn't the intent. ?ARIN policy for IPv6 is intended to allow you to > apply for that address space you can reasonably justify. > > If you don't need more than 256 subnets per site, then, there is nothing wrong > with assigning a /56 per site. ?However, if you think you might, then, a /48 per > site is prudent. > >> Turns out in subsequent discussion with ARIN that I will be able to get >> a /45 (asked for a /44 but a /45 meets my needs so that is what they >> will give me) as I believe a /45 is still a "small" allocation, I think >> I can simply have the /48 upgraded to a /45 and not pay the fee again as >> the initial /48 was never placed into service. >> > > I'm surprised they won't give you the /44. ?We're working on policy to fix that. > All of the IPv6 policies under consideration for the next meeting do rectify > this and cause ARIN to allocate IPv6 on nibble boundaries (or more). > > Owen The current end-site assignment policy seems vague. We had a similar experience, applying for a /45, realizing it was too small, applying again for a /41. After some back and forth, ARIN assigned us the /41 (no additional fee, which was fair.) We are a reasonable size campus/enterprise, spanning multiple distinct locations. We also have a good size residential Internet user base. We are increasingly structured more like a service provider, as such tends to scale well. Even a /41 seems small, when you start carving it up into /48s. A /48 per-pop for infrastructure, a /48 per-pop per enterprise customer, /56s per residential customer. I would like to avoid having to keep going back to ARIN. Plus the thought of renumbering is a non-starter, even with IPv6. I like the simplified approach that has been outlined by others: /48 no questions asked. /40 for multi-homed organizations. /32 once you push the limits of your /40. -- Tim:> From scottleibrand at gmail.com Tue Jan 19 18:03:03 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 19 Jan 2010 15:03:03 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <9e246b4d1001191435q28bcfea5p91bb732361fd9c34@mail.gmail.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <9e246b4d1001191435q28bcfea5p91bb732361fd9c34@mail.gmail.com> Message-ID: <4B563A27.80600@gmail.com> On 1/19/2010 2:35 PM, Tim Durack wrote: > > The current end-site assignment policy seems vague. We had a similar > experience, applying for a /45, realizing it was too small, applying > again for a /41. After some back and forth, ARIN assigned us the /41 > (no additional fee, which was fair.) > > We are a reasonable size campus/enterprise, spanning multiple distinct > locations. We also have a good size residential Internet user base. We > are increasingly structured more like a service provider, as such > tends to scale well. Even a /41 seems small, when you start carving it > up into /48s. A /48 per-pop for infrastructure, a /48 per-pop per > enterprise customer, /56s per residential customer. I would like to > avoid having to keep going back to ARIN. Plus the thought of > renumbering is a non-starter, even with IPv6. > Tim, It almost sounds like you're more of an ISP/LIR than an end site. Are you making /48 reassignments to your customers? If so, you should qualify for a /32 allocation under existing policy... -Scott > I like the simplified approach that has been outlined by others: > > /48 no questions asked. > /40 for multi-homed organizations. > /32 once you push the limits of your /40. > > From gbonser at seven.com Tue Jan 19 18:09:37 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 15:09:37 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B563A27.80600@gmail.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com><9e246b4d1001191435q28bcfea5p91bb732361fd9c34@mail.gmail.com> <4B563A27.80600@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72F7@RWC-EX1.corp.seven.com> > Tim, > > It almost sounds like you're more of an ISP/LIR than an end site. Are > you making /48 reassignments to your customers? If so, you should > qualify for a /32 allocation under existing policy... > > -Scott I think it depends on how many /48's you are planning to assign, doesn't it? I believe the policy says something like 200 /48's or something like that. From farmer at umn.edu Tue Jan 19 18:25:04 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Jan 2010 17:25:04 -0600 Subject: [arin-ppml] IPv6 Non-connected networks Message-ID: <4B563F50.1070306@umn.edu> This is kind of related to both 106 and 107, so I am splitting this issue off. But to start, in current policy non-connected networks that meet the criteria for an IPv4 assignment today qualify for an IPv6 assignment too. So a non-connected network with hosts for an immediate utilization of 25%, and 50% within a year, of a /20 may receive a /48. I have no idea if anyone has requested a /48 for a non-connected network, but current policy would allows that, and they are not assigned from the same block as Internet connected /48s too. So, I'm hearing some support for having these be made from ULA space, however; 1. I believe it would be necessary to put forward a RFC to enable that. These are two previous drafts; http://nsa.vix.com/~vixie/ula-global.txt http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-02 2. This would be a significant change from current IPv4 and IPv6 policy. I'd want to here a lot more support from a lot more people before moving in this direction. My intent in 107 was to continue with current policy and allow non-connected networks global addresses, but remove the host count as part of the criteria. I would also content the current text of 106 allows non-connected networks with 1000 hosts to qualify for a /48 too. At the Dearborn meeting I heard a lot of people say that ARIN shouldn't dictate routing policy. I personally would find it hard to reconcile that stance with the idea of ARIN assigning non-connected /48s from a separate block. At least without an RFC defining centrally assignable ULA addressing, then ARIN would not be defining it, the IETF would be, ARIN would only be implementing something defined by the IETF. So what is the direction the community wants to go for IPv6 non-connected networks? What do others think? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Tue Jan 19 18:31:54 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Jan 2010 17:31:54 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72F6@RWC-EX1.corp.seven.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <4B562A31.2030406@umn.edu> <5A6D953473350C4B9995546AFE9939EE081F72F6@RWC-EX1.corp.seven.com> Message-ID: <4B5640EA.9050405@umn.edu> George Bonser wrote: >> However, I think some kind of qualification of multiple sites is >> necessary. I think two offices across town from each other with 10 > host >> each and that share a common connection to the Internet probably >> shouldn't qualify for two /48s. I'm thinking of language something >> like >> this; >> >> "To qualify as a separate sites, locations must either be in separate >> cities and/or metropolitan areas, or if within the same city or >> metropolitan area to be considered separate sites each site must have >> independent connection to the Internet." >> >> So if you had two sites in different metro areas or two sites in the >> same metro area but each has a separate connection to the Internet > then >> two /48s are justified. >> >> Is that reasonable? >> > > Provided that you mean the separate connections are also to separate > providers, yes. Yea probably that too, good catch. So how about; "To qualify as separate sites, locations must either be in separate cities and/or metropolitan areas, or if within the same city or metropolitan area, each location must have an independent connection to the Internet, each from a different provider." Or is that to restrictive? So that would be a /48 per city with an additional /48 per site within a city that has a different internet provider. So if you have a network connecting locations in each of Denver, Houston, and Atlanta, 2 locations in LA with different Internet providers for each, 2 locations in Chicago with the same Internet provider, and 3 sites in NYC, 2 with the same Internet provider and 1 with a different Internet provider, would count as a total of 8 - /48 sties or a /45 assignment instead of the 10 locations with a /44 assignment. Reasonable? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From steve at ibctech.ca Tue Jan 19 18:40:54 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 19 Jan 2010 18:40:54 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B5640EA.9050405@umn.edu> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <4B562A31.2030406@umn.edu> <5A6D953473350C4B9995546AFE9939EE081F72F6@RWC-EX1.corp.seven.com> <4B5640EA.9050405@umn.edu> Message-ID: <4B564306.3060408@ibctech.ca> David Farmer wrote: > George Bonser wrote: >>> However, I think some kind of qualification of multiple sites is >>> necessary. I think two offices across town from each other with 10 >> host >>> each and that share a common connection to the Internet probably >>> shouldn't qualify for two /48s. I'm thinking of language something >>> like >>> this; >>> >>> "To qualify as a separate sites, locations must either be in separate >>> cities and/or metropolitan areas, or if within the same city or >>> metropolitan area to be considered separate sites each site must have >>> independent connection to the Internet." >>> >>> So if you had two sites in different metro areas or two sites in the >>> same metro area but each has a separate connection to the Internet >> then >>> two /48s are justified. >>> >>> Is that reasonable? >>> >> >> Provided that you mean the separate connections are also to separate >> providers, yes. > > Yea probably that too, good catch. So how about; > > "To qualify as separate sites, locations must either be in separate > cities and/or metropolitan areas, or if within the same city or > metropolitan area, each location must have an independent connection to > the Internet, each from a different provider." > > Or is that to restrictive? > > So that would be a /48 per city with an additional /48 per site within a > city that has a different internet provider. > > So if you have a network connecting locations in each of Denver, > Houston, and Atlanta, 2 locations in LA with different Internet > providers for each, 2 locations in Chicago with the same Internet > provider, and 3 sites in NYC, 2 with the same Internet provider and 1 > with a different Internet provider, would count as a total of 8 - /48 > sties or a /45 assignment instead of the 10 locations with a /44 > assignment. > > Reasonable? That math is more confusing to me than it was to decide on a numbering scheme for my /32... I guess the accountants are going to be looking after this then? Steve From gbonser at seven.com Tue Jan 19 19:02:43 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 16:02:43 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B5640EA.9050405@umn.edu> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <4B562A31.2030406@umn.edu> <5A6D953473350C4B9995546AFE9939EE081F72F6@RWC-EX1.corp.seven.com> <4B5640EA.9050405@umn.edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F72F8@RWC-EX1.corp.seven.com> > "To qualify as separate sites, locations must either be in separate > cities and/or metropolitan areas, or if within the same city or > metropolitan area, each location must have an independent connection to > the Internet, each from a different provider." > > Or is that to restrictive? > Maybe a different way of wording it might be: "or if within the same city or metropolitan area, each location must be multihomed with unique provider connections appearing in separate locations" which would cover the case with, say, three facilities in a region that are linked together. Two of the facilities have internet access but from two different providers. The third facility leverages the existing internet connectivity from the other two. In other words, the organization has some backhaul between offices that it leverages to basically be the ISP for the third location using that infrastructure. That is actually how we have been putting things together. If you have two production facilities in a region with two different data centers with two different transit providers, and if you link the two together you can then multihome both. And if you have an office in the same region, you toss a link to the office from one or both of the data centers to serve the office out of that same infrastructure so you leverage your existing production transit contracts for office use as well. In this case the office does not have a connection to a separate provider so your wording of "each location must have an independent connection to the Internet" would not apply though the design described above does fit within the spirit of what you intended (I think). So basically multiple locations in a region (any number) with shared infrastructure that has at least two diverse paths to the internet from separate facilities to separate providers is what you are after, I think. From farmer at umn.edu Tue Jan 19 20:33:21 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Jan 2010 19:33:21 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <9e246b4d1001191435q28bcfea5p91bb732361fd9c34@mail.gmail.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <9e246b4d1001191435q28bcfea5p91bb732361fd9c34@mail.gmail.com> Message-ID: <4B565D61.1040904@umn.edu> Tim Durack wrote: > I like the simplified approach that has been outlined by others: > > /48 no questions asked. I don't believe in no questions asked, but I'll go for only a few questions asked. Like are you multi-homed, or why a ISP or LIR assignment will not satisfy your need, and a subnet plan > /40 for multi-homed organizations. Why a /40 if you are multihomed, what does that have to do with how many addresses you need? Did you mean have multiple site? Then OK, sure. > /32 once you push the limits of your /40. > So then do you support something like PP#106? Any change you think should be made to PP#106 as it currently is written? If people support or oppose the direction of PP#106 the AC needs to here you say that one way or the other and the more clearly you say it one way or the other the better. FYI, the AC needs to settle on text for Draft Policies and get it to Staff by Feb 1 or so. This is in order to have legal and staff reviews back in time to take action at our February AC meeting. Which without a special AC meeting, is our last opportunity to move a proposal forward to Draft Policy and get it on the agenda for Toronto. We can still make changes to text up to 30 days before the Toronto meeting, but it would be best if those were not major rewrites, only minor changes. So that gives a little more than a week for major changes, so any feed back you can give us in the next week or so will be most useful. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From gbonser at seven.com Tue Jan 19 22:53:28 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Jan 2010 19:53:28 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B565D61.1040904@umn.edu> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com><9e246b4d1001191435q28bcfea5p91bb732361fd9c34@mail.gmail.com> <4B565D61.1040904@umn.edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7305@RWC-EX1.corp.seven.com> > > So then do you support something like PP#106? > > Any change you think should be made to PP#106 as it currently is > written? > > If people support or oppose the direction of PP#106 the AC needs to > here > you say that one way or the other and the more clearly you say it one > way or the other the better. I would say that I generally support 106 but would also support a slight modification of prop 106. For multihomed end users, I would expand the number of different allocations from 3 to 4. Instead of: /48, /40, and /32 I would support: /48, /44, /40, and /32 A /44 allocation would serve many organizations with all the addressing they would ever need. If you look at the number of individual multi-homed end users, I believe a relatively small percentage of the total number of them needing more than a /48 would make use of more than a /44 as most such organizations are relatively small. So it would be something like: /48 for a single multihomed location, /44 for small multiple site multihomed, /40 for medium multiple site multihomed, /32 for large. I believe the majority of organizations would be able to get the right sized assignment the first time and it does offer some address conservation from giving everyone a /40. Of course, the problem comes in when someone grows across the boundary and needs more space. Nobody wants to renumber. And that is the part where I am having a problem coming up with a good suggestion to deal with. Initial assignments aren't the problem, the problem would seem to be how to handle growth across boundaries without forcing someone to renumber their existing space if they don't want to. The closest thing I can come to that might work is something like this: If your initial assignment was a /48 then a /44 space is "blocked out" for you to grow into. If you grow and require additional space, you are given the remainder of the /44. If you have a /44 and now require additional space you are given a /40 *AND* allowed to keep your initial /44 if the /40 block from which your /44 was taken is not completely available for issue. If you have a /40 and now require additional space you are given a /32 *AND* allowed to keep your /40 if the /32 from which your /40 was taken is not completely available for issue. This is very important, I believe, because it addresses one of the psychological reasons why people often want more space than they need. Renumbering is not desired nor is maintaining a myriad of disconnected blocks. If they can get a /40 now and know that if they grow to the point of qualifying for a /32, if there isn't sufficient space adjacent to their existing allocation, they won't have to renumber. Having an extra /40 in addition to a /32 represents less than 1% of their address space. Organizations would be encouraged to return the initial smaller allocations but not forced to do so. Maybe they could be encouraged to do so via an annual surcharge as long as they hold the extra addresses or something. I think this would result in less address "waste" than simply giving everyone with multiple sites a /40 as most of these organizations will have only a small number of locations anyway and a /44 would serve most of them forever. George From joelja at bogus.com Wed Jan 20 01:22:12 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 19 Jan 2010 22:22:12 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <14568.1263931361@marajade.sandelman.ca> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com> <20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> Message-ID: <4B56A114.9010607@bogus.com> Michael Richardson wrote: >>>>>> "Leo" == Leo Bicknell writes: > Leo> "ARIN charges a fee for the initial IPv6 allocation from > Leo> ARIN to an ISP. This fee is currently waived for IPv4 > Leo> subscribers. For organizations that aren't IPv4 subscribers, > Leo> the fee is lowered by current fee waivers." > > Leo> t=3: Pay $1250, the max of: $1250 for the IPv4 renewal $1250 > Leo> for the IPv6 renewal > > Leo> "Organizations issued or transferred both IPv4 and IPv6 > Leo> allocations by ARIN under a single Org ID pay the larger of the > Leo> two annual renewal fees." > > Leo> Now, let's compare with the cost of just doing IPv4, which > Leo> would be $1250 per year. Humm, let's see, it costs $0 more to > Leo> get IPv6 address space (right now). > > Leo> So, let's try this again. Will your manager approve $0? > > Cost of 10.0.0.0/24 = $0. > Cost of IPv6, > $0. It's awesome that large scale NAT costs you zero dollars. I don't think that experience is shared by other service providers however. From joelja at bogus.com Wed Jan 20 01:41:55 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 19 Jan 2010 22:41:55 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B562A31.2030406@umn.edu> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <4B562A31.2030406@umn.edu> Message-ID: <4B56A5B3.2050700@bogus.com> David Farmer wrote: > George Bonser wrote: > >> The problem is, being multihomed, nobody is going to take a /56 >> announcement for a site and while we do have our sites in the SF Bay >> area interconnected and our policy is to announce an aggregate route, we >> have upstream transit and peering at the individual sites and if >> anything should happen to the backhaul between the sites we would need >> to deaggregate the announcement. Most will take a /48 announcement from >> PI space, practically nobody (aside from the immediate upstream) would >> take a /56. We played with the notion of being able to announce a /56 >> if all sites had access to the same upstreams and having them aggregate >> it to their peers but realized that the current "best practice" is to >> simply announce a /48 or better. >> >> And we plan of expansion outside of the area that are likely going to be >> discrete networks so again, a /48 is the only thing that is going to >> work. >> >> >>> I'm surprised they won't give you the /44. We're working on policy to >>> fix that. >>> All of the IPv6 policies under consideration for the next meeting do >>> rectify >>> this and cause ARIN to allocate IPv6 on nibble boundaries (or more). >>> >>> Owen >> >> I suppose they can only go by their current policy guidelines and >> apparently it is policy to allocate only what is needed for the >> immediate foreseeable future. > > After reading this and a couple other posting, within PP#107 I want to > make explicit that multiple sites are a justification for larger than a > /48. > > However, I think some kind of qualification of multiple sites is > necessary. I think two offices across town from each other with 10 host > each and that share a common connection to the Internet probably > shouldn't qualify for two /48s. I'm thinking of language something like > this; > > "To qualify as a separate sites, locations must either be in separate > cities and/or metropolitan areas, or if within the same city or > metropolitan area to be considered separate sites each site must have > independent connection to the Internet." Two or more Data Centers, Campuses, factories or branch offices in the same metro may well require additional prefixes. They may be seperate by design, or separable at some later date, separable for DR purposes, discrete based on function, etc. > So if you had two sites in different metro areas or two sites in the > same metro area but each has a separate connection to the Internet then > two /48s are justified. > > Is that reasonable? > From michael.dillon at bt.com Wed Jan 20 04:28:28 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 20 Jan 2010 09:28:28 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <4B5640EA.9050405@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C49745804E149D5@E03MVZ2-UKDY.domain1.systemhost.net> > "To qualify as separate sites, locations must either be in separate cities and/or metropolitan areas, or if within the same city or metropolitan area, each location must have an independent connection to the Internet, each from a different provider." I don't believe in redefining the English language. A site, is what the dictionary says, regardless of how it is connected to the Internet. It is common for companies with several sites to have them all connected to the Internet via a gateway at a central site. Nevertheless, it would be ridiculous for ARIN to treat this a single site. The number one most important element of a site, in IPv6 networking terms, is that it justifies using a separate /48 prefix. Then if the ownership of the site changes, the new owner can keep the network topology intact and only change the /48 prefix for one of their own. The reason a site is not called a building or an address is that a site could be a single floor in an office building, or one office above the dry cleaners, or a single apartment, or it could even be floors 17 through 26 of a skyscraper, where those floors are all housing the same insurance company. The definition of a site is purposely a bit vague and we should not tamper with it. In particular, since there is no need to be precise about allocation sizes, there is no need to be precise about the site definition. --Michael Dillon From mysidia at gmail.com Wed Jan 20 08:50:26 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 20 Jan 2010 07:50:26 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <28E139F46D45AF49A31950F88C49745804E149D5@E03MVZ2-UKDY.domain1.systemhost.net> References: <4B5640EA.9050405@umn.edu> <28E139F46D45AF49A31950F88C49745804E149D5@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <6eb799ab1001200550o60ecead5q1f3fe9ed2aad844e@mail.gmail.com> On Wed, Jan 20, 2010 at 3:28 AM, wrote: ... > I don't believe in redefining the English language. A site, is what the > dictionary says, regardless of how it is connected to the Internet. --- The word "end site" in no way implies a single physical location any more than the term "web site" implied a single physical location, or that the term "web farm" suggests an actual farm with webservers installed in the barn, to keep the animals company; the dictionary is for providing common-use definitions only. The dictionary does not answer for technical or subject-matter-specific definitions like the IPv6-specific word "end-site" It's the intent of the design, and good technical practice that matter. The usage of "End site" in IPv6 documents has a very similar meaning to the word "autonomous system" or what ARIN NRPM calls an "end user network". "End site" doesn't mean "physical place"... it means "IP-specific site", as in the logical presence in the IPv6 address space created by that end-user's network. >>> NRPM has already done that: "2.10. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment " > It is common for companies with several sites to have them all connected > to the Internet via a gateway at a central site. Nevertheless, it would > be ridiculous for ARIN to treat this a single site. It's not that ridiculous. It is probably more ridiculous to suggest that each of one end user network's physical locations really needs an additional /48 I believe /48 is selected on the assumption that all the end user's subnets would be taken from their one /48. If each physical location receives its own allocation, then there's really no reason to pick /48 over /56. A large number of subnets at a single physical location is quite rare. Whereas, there are very good reasons to assign an end-site a /48 if that end-site comprises many geographic locations, then a large number of subnets is likely -- -J From michael.dillon at bt.com Wed Jan 20 10:37:40 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 20 Jan 2010 15:37:40 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <6eb799ab1001200550o60ecead5q1f3fe9ed2aad844e@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804E1508D@E03MVZ2-UKDY.domain1.systemhost.net> > The word "end site" in no way implies a single physical location > any more than the term "web site" implied a single physical location, > or that the term "web farm" suggests an actual farm with > webservers installed in the barn, to keep the animals company; > the dictionary > is for providing common-use definitions only. Just so that we are speaking a common language here, let's check Merriam-Webster online... 1 a : the spatial location of an actual or planned structure or set of structures (as a building, town, or monuments) b : a space of ground occupied or to be occupied by a building 2 a : the place, scene, or point of an occurrence or event b : one or more Internet addresses at which an individual or organization provides information to others ; especially : web site That is where 99% of people will begin, including technical people because most people get their definitions of terms from common usage, not from RFC lawyering. If ARIN policy conflicts with common usage, then eventually ARIN policy will have to change because we do not have a body of ARIN case law to expound upon the meaning of word and phrases, nor do we have a panel of ARIN judges to ponder the matter and write learned opinions. > The dictionary > does not answer for technical or subject-matter-specific > definitions like the IPv6-specific word "end-site" The dictionary only reflects common usage as you will note in Merriam-Webster's inclusion of the term "web site". > It's the intent of the design, and good technical practice that matter. > The usage of "End site" in IPv6 documents has a very similar meaning > to the word "autonomous system" or what ARIN NRPM calls an "end user network". No it does not. If it did, then 2.10 of the NRPM would say so instead of saying: 2.10. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment > "End site" doesn't mean "physical place"... it means > "IP-specific site", as in the logical presence in the IPv6 > address space created by that end-user's network. An end site is like the physical place at the end of a driveway. Of course we all know that it is not physical but the analogy of a packet transport network with a path that ends somewhere, is understood by all. > It is common for companies with several sites to have them all > connected to the Internet via a gateway at a central site. > Nevertheless, it would be ridiculous for ARIN to treat this a single site. It's not that ridiculous. Yes it is. ARIN does not need to nickel and dime everything to the nth degree with IPv6 addressing because it would create a two-tier system of IPv6 addressing. Inside an LIR with their /32 or bigger, they can follow a liberal model of assigning a /48 to anything that might be an end site, and still meet their HD ratio targets to get more. But for the lowly peasants who get an assignment from ARIN, they have to suffer under a strict regime designed to squeeze every spare ounce of blood from them. That is a ridiculous state of affairs and one which we must avoid in crafting IPv6 policy. Owen's example of rounding up to the nearest hexadecimal digit, is a good example of the way in which we should approach the problem. > I believe /48 is selected on the assumption that all the end user's > subnets would be taken from their one /48. All of the end site's subnets... And end user or customer, could well have more than one site, and could connect those sites together using an IP-MPLS VPN from another provider. Nevertheless, every end site is still a site, even if you only provide a single 1G circuit to that customer at their central site. > If each physical location receives its own allocation, then there's > really no reason to pick /48 over /56. A large number of > subnets at a single physical location is quite rare. Sure there is, the RFCs and the NRPM allow for assigning a /48 to every site. Using a /56 is optional and should only be considered for end sites which are private residences. The choice of a /48 was so that each end site receives so many /64 subnets that they are highly unlikely to ever run out, no matter how much their network expands internally. Clearly, even a small commercial site has much more potential for growth than a large private residence, thus the distinction. LIRs should never judge whether or not an end-site needs all the /64 subnets that they are assigned. Regardless of the nature of the private residence they should all get the same assignment size which would be /56 or /48 depending on your overall architecture and plans. And non-residential sites should always get a /48. There will be a very few exceptions to this mostly in the case of things that look a bit like an LIR/ISP but aren't such as a large corporate's data center where a single site needs more than one /48. Generally, you can expect these things to look like a single end site from the outside, but have some kind of internal partitioning that makes it more like a bunch of sites bundled together, rather like a hosting ISP who rents cages to other companies. We have to avoid making the mistake of imposing a scarcity regime in the land of plenty because to do so will create inequities and lead to legal challenges of ARIN's activities. --Michael Dillon From kkargel at polartel.com Wed Jan 20 10:48:51 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 20 Jan 2010 09:48:51 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F72F8@RWC-EX1.corp.seven.com> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B098E@XCH-NW-05V.nw.nos.boeing.com><0267B5481DCC474D8088BF4A25C7F1DF55127B0999@XCH-NW-05V.nw.nos.boeing.com><20100118210831.GA74082@ussenterprise.ufp.org> <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <4B562A31.2030406@umn.edu> <5A6D953473350C4B9995546AFE9939EE081F72F6@RWC-EX1.corp.seven.com> <4B5640EA.9050405@umn.edu> <5A6D953473350C4B9995546AFE9939EE081F72F8@RWC-EX1.corp.seven.com> Message-ID: <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of George Bonser > Sent: Tuesday, January 19, 2010 6:03 PM > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] V6 address allocation policy > > > "To qualify as separate sites, locations must either be in separate > > cities and/or metropolitan areas, or if within the same city or > > metropolitan area, each location must have an independent connection > to > > the Internet, each from a different provider." > > > > Or is that to restrictive? > > > > Maybe a different way of wording it might be: > > "or if within the same city or metropolitan area, each location must be > multihomed with unique provider connections appearing in separate > locations" > > which would cover the case with, say, three facilities in a region that > are linked together. Two of the facilities have internet access but > from two different providers. The third facility leverages the existing > internet connectivity from the other two. In other words, the > organization has some backhaul between offices that it leverages to > basically be the ISP for the third location using that infrastructure. > > That is actually how we have been putting things together. If you have > two production facilities in a region with two different data centers > with two different transit providers, and if you link the two together > you can then multihome both. And if you have an office in the same > region, you toss a link to the office from one or both of the data > centers to serve the office out of that same infrastructure so you > leverage your existing production transit contracts for office use as > well. > > In this case the office does not have a connection to a separate > provider so your wording of "each location must have an independent > connection to the Internet" would not apply though the design described > above does fit within the spirit of what you intended (I think). > > So basically multiple locations in a region (any number) with shared > infrastructure that has at least two diverse paths to the internet from > separate facilities to separate providers is what you are after, I > think. > My take on this is that who the different sites have for a provider is not as important as the routing policy. Perhaps 'irreconcilable routing policies' might be a better discriminator. It is very possible for one company to have two sites within a community served by a single provider, and each site requires completely disparate routing and has separate responsible administrators and technical staff. In that case shouldn't the two sites be running out of separate IP spaces? On the other hand one company might have two sites running in two different communities through the same provider with a common routing policy. These two sites could use a common IP space. My company provides connectivity all across the eastern part of our state. Insurance companies, hospitals and farms commonly have satellite premises in different communities that could route as a single unit. (FWIW farms nowadays are technically advanced big businesses) I don't see that (community AND provider) is functional as a determiner. Perhaps (community AND provider AND POC) would work. From bill at herrin.us Wed Jan 20 11:15:52 2010 From: bill at herrin.us (William Herrin) Date: Wed, 20 Jan 2010 11:15:52 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <6eb799ab1001200550o60ecead5q1f3fe9ed2aad844e@mail.gmail.com> References: <4B5640EA.9050405@umn.edu> <28E139F46D45AF49A31950F88C49745804E149D5@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab1001200550o60ecead5q1f3fe9ed2aad844e@mail.gmail.com> Message-ID: <3c3e3fca1001200815ob88a6a7h3eb3c2a450abee40@mail.gmail.com> On Wed, Jan 20, 2010 at 8:50 AM, James Hess wrote: > On Wed, Jan 20, 2010 at 3:28 AM, ? wrote: >> It is common for companies with several sites to have them all connected >> to the Internet via a gateway at a central site. Nevertheless, it would >> be ridiculous for ARIN to treat this a single site. > > It's not that ridiculous. > It is probably more ridiculous to suggest that each of ? one ?end user > network's ?physical locations ?really needs an ?additional ? /48 > > I ?believe ?/48 ?is ?selected ?on the assumption that ?all the ?end > user's ?subnets ?would be taken from their ?one /48. > > If ?each physical location receives its own allocation, then there's > really ?no reason to ?pick /48 ?over /56. ? ? ?A large number of > subnets at a single physical location is quite rare. Or to put a different spin on it: IPv6's routing and addressing architecture is directly sensitive to: LAN count (hard) Multihoming (hard) Administrative system boundaries (moderate) Renumbering (soft) It is not directly sensitive to: Host count Physical location Many many other factors important to various SIGs. That's why Multiple Distinct Networks (administrative boundary) is an important difference that merits additional /48's while multiple POPs (physical location) is not. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kkargel at polartel.com Wed Jan 20 11:39:34 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 20 Jan 2010 10:39:34 -0600 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100120161048.GA447@vacation.karoshi.com.> References: <14568.1263931361@marajade.sandelman.ca> <5A6D953473350C4B9995546AFE9939EE081F72E9@RWC-EX1.corp.seven.com> <5917652C-3F39-494F-8B2A-64F2AEC0B38F@delong.com> <5A6D953473350C4B9995546AFE9939EE081F72EC@RWC-EX1.corp.seven.com> <4B562A31.2030406@umn.edu> <5A6D953473350C4B9995546AFE9939EE081F72F6@RWC-EX1.corp.seven.com> <4B5640EA.9050405@umn.edu> <5A6D953473350C4B9995546AFE9939EE081F72F8@RWC-EX1.corp.seven.com> <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> <20100120161048.GA447@vacation.karoshi.com.> Message-ID: <8695009A81378E48879980039EEDAD28876D3ECD@MAIL1.polartel.local> > > welcome to the concept of an ASN. > > --bill Perhaps I am misunderstanding but I thought this was rather the point of the discussion, multiple allocations to a single ASN.. If the issue is resolved by the company simply acquiring multiple ASN's for disparate network entities then the whole discussion is pointless or people just don't like the solution that is in place. From michael.dillon at bt.com Wed Jan 20 12:49:48 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 20 Jan 2010 17:49:48 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> Message-ID: <28E139F46D45AF49A31950F88C49745804E1526E@E03MVZ2-UKDY.domain1.systemhost.net> > On the other hand one company might have two sites running in > two different communities through the same provider with a > common routing policy. These two sites could use a common IP > space. My company provides connectivity all across the > eastern part of our state. Insurance companies, hospitals > and farms commonly have satellite premises in different > communities that could route as a single unit. (FWIW farms > nowadays are technically advanced big businesses) If you give the customer a /48 for each of the individual sites that CURRENTLY function as parts of a single unit, you can't go wrong. If the customer doesn't want to actually use all of the /48s, it won't hurt anyone for them to gather dust for a few years. Then, when they come back for more addresses because they sold of part of the business, including one of the sites, you can remind them that they could have just used that /48 in the first place and saved themselves some grief. The story will make the rounds as a case study, and future network designers will be sure to use a discrete /48 block per discrete physical site so that they are not burned in the future. That's how best practices get created. > I don't see that (community AND provider) is functional as a > determiner. Perhaps (community AND provider AND POC) would work. No. Street address is the best thing we have. If there are two different street addresses, then there are two different sites. Even if it is units 17 and 18 of the strip mall at 123 anywhere lane, it is still two sites. --Michael Dillon From michael.dillon at bt.com Wed Jan 20 12:56:24 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 20 Jan 2010 17:56:24 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <3c3e3fca1001200815ob88a6a7h3eb3c2a450abee40@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804E15279@E03MVZ2-UKDY.domain1.systemhost.net> > IPv6's routing and addressing architecture is directly sensitive to: > > LAN count (hard) > Multihoming (hard) > Administrative system boundaries (moderate) Renumbering (soft) > > It is not directly sensitive to: > > Host count > Physical location > Many many other factors important to various SIGs. > > That's why Multiple Distinct Networks (administrative > boundary) is an important difference that merits additional > /48's while multiple POPs (physical location) is not. Wrong. You only get easy renumbering if you give each physical location the same fixed length prefix. Every PoP should have its own /48 for all internal and infrastructure use. Even if it is only a rack in a colo, it is still a separate end site. You may someday move everything from that rack into its own building, and the /48 numbering scheme that you used from day one will make the move simple. There is no shortage of IPv6 addresses. Assigning a /48 to an end-site of any sort is fully justified in the HD ratio calculations, etc. --Michael Dillon P.S. There is no good reason to nickel and dime people to death over a measly speck of dust fragment of the amount of address space currently used to number a single IPv4 host. That /48 is 1/65536th of a /32. What is the point of DUST CONSERVATION!? From cra at WPI.EDU Wed Jan 20 13:13:02 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 20 Jan 2010 13:13:02 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <28E139F46D45AF49A31950F88C49745804E1526E@E03MVZ2-UKDY.domain1.systemhost.net> References: <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> <28E139F46D45AF49A31950F88C49745804E1526E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20100120181302.GW2591@angus.ind.WPI.EDU> On Wed, Jan 20, 2010 at 05:49:48PM -0000, michael.dillon at bt.com wrote: > No. Street address is the best thing we have. If there are two > different street addresses, then there are two different sites. > Even if it is units 17 and 18 of the strip mall at 123 anywhere > lane, it is still two sites. Great. So for my campus which is made up of 50 different street addresses I can get 50 /48s... From bill at herrin.us Wed Jan 20 13:44:48 2010 From: bill at herrin.us (William Herrin) Date: Wed, 20 Jan 2010 13:44:48 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <28E139F46D45AF49A31950F88C49745804E15279@E03MVZ2-UKDY.domain1.systemhost.net> References: <3c3e3fca1001200815ob88a6a7h3eb3c2a450abee40@mail.gmail.com> <28E139F46D45AF49A31950F88C49745804E15279@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca1001201044m60540b3dve80b09a336366d5b@mail.gmail.com> On Wed, Jan 20, 2010 at 12:56 PM, wrote: > Wrong. You only get easy renumbering if you give each physical > location the same fixed length prefix. Every PoP should have > its own /48 for all internal and infrastructure use. Even if > it is only a rack in a colo, it is still a separate end site. > You may someday move everything from that rack into its own > building, and the /48 numbering scheme that you used from day > one will make the move simple. > > There is no shortage of IPv6 addresses. Assigning a /48 to an > end-site of any sort is fully justified in the HD ratio > calculations, etc. Why not /44, /52, or /56? Why in your master plan must this size be /48? If your answer involves disaggregating locations from each other, I refer to to NRPM 6.3.8. More generally I'll point out that when organizations merge, divide, consolidate and reorganize they tend to do so by a relatively arbitrary combination of business function and customer scope, not by physical location. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed Jan 20 13:55:01 2010 From: bill at herrin.us (William Herrin) Date: Wed, 20 Jan 2010 13:55:01 -0500 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100120181302.GW2591@angus.ind.WPI.EDU> References: <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> <28E139F46D45AF49A31950F88C49745804E1526E@E03MVZ2-UKDY.domain1.systemhost.net> <20100120181302.GW2591@angus.ind.WPI.EDU> Message-ID: <3c3e3fca1001201055r4031e53bl85addd301923d4d@mail.gmail.com> On Wed, Jan 20, 2010 at 05:49:48PM -0000, michael.dillon at bt.com wrote: >> No. Street address is the best thing we have. If there are two >> different street addresses, then there are two different sites. >> Even if it is units 17 and 18 of the strip mall at 123 anywhere >> lane, it is still two sites. Why stop there? Obviously every box at the post office needs its own /48 and the ones at the UPS store should surely get two. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony at lava.net Wed Jan 20 14:07:30 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 20 Jan 2010 09:07:30 -1000 (HST) Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100120181302.GW2591@angus.ind.WPI.EDU> References: <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> <28E139F46D45AF49A31950F88C49745804E1526E@E03MVZ2-UKDY.domain1.systemhost.net> <20100120181302.GW2591@angus.ind.WPI.EDU> Message-ID: On Wed, 20 Jan 2010, Chuck Anderson wrote: > Great. So for my campus which is made up of 50 different street > addresses I can get 50 /48s... You could but you'd be better off asking for a /32 and dole out /48s to each site. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From whinery at hawaii.edu Wed Jan 20 14:18:35 2010 From: whinery at hawaii.edu (Alan Whinery) Date: Wed, 20 Jan 2010 09:18:35 -1000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <3c3e3fca1001201055r4031e53bl85addd301923d4d@mail.gmail.com> References: <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> <28E139F46D45AF49A31950F88C49745804E1526E@E03MVZ2-UKDY.domain1.systemhost.net> <20100120181302.GW2591@angus.ind.WPI.EDU> <3c3e3fca1001201055r4031e53bl85addd301923d4d@mail.gmail.com> Message-ID: <4B57570B.7070101@hawaii.edu> Individual P.O. Boxes only get /64, per the "superfluous IPv6 allocation" draft (expired) On 1/20/2010 8:55 AM, William Herrin wrote: > On Wed, Jan 20, 2010 at 05:49:48PM -0000, michael.dillon at bt.com wrote: > >>> No. Street address is the best thing we have. If there are two >>> different street addresses, then there are two different sites. >>> Even if it is units 17 and 18 of the strip mall at 123 anywhere >>> lane, it is still two sites. >>> > Why stop there? Obviously every box at the post office needs its own > /48 and the ones at the UPS store should surely get two. > > Regards, > Bill Herrin > > > From joelja at bogus.com Wed Jan 20 13:54:41 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 20 Jan 2010 10:54:41 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100120181302.GW2591@angus.ind.WPI.EDU> References: <8695009A81378E48879980039EEDAD28876D3EC5@MAIL1.polartel.local> <28E139F46D45AF49A31950F88C49745804E1526E@E03MVZ2-UKDY.domain1.systemhost.net> <20100120181302.GW2591@angus.ind.WPI.EDU> Message-ID: <4B575171.3000809@bogus.com> Chuck Anderson wrote: > On Wed, Jan 20, 2010 at 05:49:48PM -0000, michael.dillon at bt.com wrote: >> No. Street address is the best thing we have. If there are two >> different street addresses, then there are two different sites. >> Even if it is units 17 and 18 of the strip mall at 123 anywhere >> lane, it is still two sites. > > Great. So for my campus which is made up of 50 different street > addresses I can get 50 /48s... If you wired up your campus in 1990 you probably got a /16 worth of v4, right about now that probably seeming kind of tight. In a previous job, I assigned each of the network labs on our mountain view campus a separate /48, being discrete entities with their own allocation policy and requirements (albiet with a common upstream) that seemed like quite a reasonable approach. In the current job we have seperate /48s set aside for the Redwood Shores campus and the colocation facility in santa-clara given their diverse functions. The requirements are somewhat idiosyncratic to the respective companies and the former received it's /32 in 2000 whereas the later received a /43 in 2009. _______________________________________________ > 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.dillon at bt.com Thu Jan 21 03:55:06 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 21 Jan 2010 08:55:06 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <3c3e3fca1001201044m60540b3dve80b09a336366d5b@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804E153C0@E03MVZ2-UKDY.domain1.systemhost.net> > Why not /44, /52, or /56? Why in your master plan must this > size be /48? Not my master plan. Read the RFCs. /48 is the assignment for an end site unless they can justify needing more space. /44 is reasonable if they need two or three times the number of /64 subnets at a site, maybe a sprawling auto factory. If you are a big ISP and you have a huge number of private residences connected, you may wish to assign a /56 to private residence sites because it simplifies your overall address accounting. /52 is just plain wierd and should never happen outside the lab. > More generally I'll point out that when organizations merge, > divide, consolidate and reorganize they tend to do so by a > relatively arbitrary combination of business function and > customer scope, not by physical location. Physical locations do change hands during mergers. If you want to consolidate your ISP supplier contracts and move the new locations to favored ISP supplier X, just swap the /48 prefix and do the usual IPv6 renumber dance. Job done. No need to rearchitect their local area network. Simples! --Michael Dillon From michael.dillon at bt.com Thu Jan 21 03:57:55 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 21 Jan 2010 08:57:55 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <3c3e3fca1001201055r4031e53bl85addd301923d4d@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804E153CB@E03MVZ2-UKDY.domain1.systemhost.net> > Why stop there? Obviously every box at the post office needs its own > /48 and the ones at the UPS store should surely get two. No, because the post office and the UPS store are single sites. They would each have a /48 and how they number their boxes would be an internal matter. I would expect them to use /128's per box, if and only if, the boxes (or their locking mechanisms) become networked. Same thing for the light bulbs but they would be on a different /64 subnet. --Michael Dillon From michael.dillon at bt.com Thu Jan 21 03:49:22 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 21 Jan 2010 08:49:22 -0000 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <20100120181302.GW2591@angus.ind.WPI.EDU> Message-ID: <28E139F46D45AF49A31950F88C49745804E153B2@E03MVZ2-UKDY.domain1.systemhost.net> > Great. So for my campus which is made up of 50 different > street addresses I can get 50 /48s... Precisely. That's the way that the IPv6 designers intended it to be. If one of those locations decides to build a lab which does some kind of mobile device experimentation, and they need 10,000 /64 subnets, you have no problems because their /48 has plenty to spare. One of the outcomes of IPv6 is that as far as possible, networks will have more than enough address space so that they can expand without renumbering. The /64 subnet will never run out of interface addresses. For 99% of sites, their /48 will never run out of /64 blocks, and for 80% of LIRs/ISPs, their /32 will never run out of /48 site assignments. And in the private residences, as long as they remain private residences, that /56 will never run out of /64 subnets even when they put in a mother-in-law suite. --Michael Dillon From gbonser at seven.com Thu Jan 21 04:27:26 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Jan 2010 01:27:26 -0800 Subject: [arin-ppml] V6 address allocation policy In-Reply-To: <28E139F46D45AF49A31950F88C49745804E153B2@E03MVZ2-UKDY.domain1.systemhost.net> References: <20100120181302.GW2591@angus.ind.WPI.EDU> <28E139F46D45AF49A31950F88C49745804E153B2@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F732B@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Thursday, January 21, 2010 12:49 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] V6 address allocation policy > > > Great. So for my campus which is made up of 50 different > > street addresses I can get 50 /48s... > > Precisely. That's the way that the IPv6 designers intended it > to be. If one of those locations decides to build a lab which > does some kind of mobile device experimentation, and they need > 10,000 /64 subnets, you have no problems because their /48 has > plenty to spare. There is more to it than that. IP addresses will now be used for more things than simply connectivity. Imagine you have clients out there that have a 64-bit GUID that identifies them. Now imagine you have server software on a farm of servers that handle those users but for some reason you want the user to be "sticky" to the server that is handling them. In the past this was dealt with using various kinds of clustering or shared memory software and cookies or something. Now you don't need to do that. The server "handling" that user creates a host IP that is the user's GUID. That makes it really easy to find the correct host that should be handling that user. IP addresses are going to be used for lots of things now that we couldn't use them for before. OS kernel developers are going to be getting hit with people wanting to program tens of thousands of IP addresses on servers. From info at arin.net Thu Jan 21 14:41:27 2010 From: info at arin.net (Member Services) Date: Thu, 21 Jan 2010 14:41:27 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2010 Message-ID: <4B58ADE7.6050705@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 15 January 2010 and made decisions about several policy proposals. The AC selected the following proposals as draft policies for adoption discussion online and at the April Public Policy Meeting in Toronto. Each draft policy will be posted shortly to the PPML. 99. /24 End User Minimum Assignment Unit 97. Waiting List for Unmet IPv4 Requests The AC accepted the following proposals on to the AC's docket for development and evaluation. 106. Simplified IPv6 policy 105. Simplified M&A transfer policy The AC abandoned Policy Proposal 95. Customer Confidentiality. The AC stated: "The Advisory Council concluded that this proposal closely duplicates one recently presented before the community. The community vetted the earlier proposal at a Public Policy Meeting and on PPML in great detail resulting in the proposal failing to gain enough support to move forward in the Policy Development Process (PDP). The pro's and con's of PP95 were discussed at the AC meeting held on 15 January 2010, and in the AC's opinion there has not been a significant change in technology or nature and PP95 should not move forward in the PDP. In addition, existing policy permits privacy regarding private residences, addressing the primary privacy issue that the community has shown support for in recent history. The AC believes that moving PP95 forward would not result in any benefit to the Internet Community and therefore has chosen to abandon it." The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? The abandonment of proposal 95 may be petitioned. The original versions of proposals 97 and 99 may also be petitioned (if the original text is preferred over the resulting draft policy text). The purpose of a petition would be to change the proposal into a draft policy for discussion on the Public Policy Mailing List and at the April meeting. The deadline to begin a petition is 28 January 2010. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Jan 21 14:45:25 2010 From: info at arin.net (Member Services) Date: Thu, 21 Jan 2010 14:45:25 -0500 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests Message-ID: <4B58AED5.4030705@arin.net> Draft Policy 2010-1 Waiting List for Unmet IPv4 Requests On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting List for Unmet IPv4 Requests" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Toronto in April. The draft was developed by the AC from Policy Proposal "97. Waiting List for Unmet IPv4 Requests". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, including the original proposal text. Draft Policy 2010-1 is below and can be found at: https://www.arin.net/policy/proposals/2010_1.html You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-1 Waiting List for Unmet IPv4 Requests Version/Date: 21 January 2010 Policy statement: Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN attempts to issue blocks of addresses on appropriate "CIDR-supported" bit boundaries. As long as sufficient space is available, ARIN may reserve space to maximize aggregation possibilities. ARIN will make each allocation and assignment as a single continuous range of addresses. Add new section 4.1.8: 4.1.8 Unmet requests In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to either modify their request and request a smaller size block, or be placed on a waiting list of pre-qualified recipients. Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document an unforeseen change in circumstances since their last request. Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. 4.1.8.1 Waiting list The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. 4.1.8.2 Fulfilling unmet needs As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. 8. Rationale: ARIN will soon be unable to meet all approved requests for IPv4 address space. In the absence of a policy like this, it is unclear what ARIN should do with subsequent requests. This policy would allocate reclaimed address blocks (and the last of the ARIN free pool) on a first-come-first-served basis, while preserving aggregation to the degree possible. As the free pool shrinks, requests larger than the largest block left would be placed on a waiting list, while smaller requests would use up the rest of it, until all requests have to go on the waiting list. As additional reclaimed addresses become available, the requests that have been waiting the longest would be met first. If a requester gets the addresses they need via transfer, then they would be removed from the waiting list and would need to wait and submit a new request for additional address space, either directly or via transfer. FAQ: Q1: The effect of 2009-8, if implemented by the Board, is to allow transfers to be up to a 12 month supply of resources and up to a 3 month supply for resource from the ARIN free pool. Does that jive with your intent for this policy? A1: Correct. After we get to the last /8, you can request up to a 3-month supply from the free pool, but only every 3 months unless you can document an unforeseen change in circumstances since your last request. However, if you get the space via transfer, you can get a block big enough for 12 month's need, and if you end up using it up faster, you can submit another request after 3 months. Q2: If I were on the waiting list, and subsequently received a transfer via 8.3, would I be removed from the waiting list? A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer will be considered fulfilled and removed from the waiting list." Q3: Would receipt of an M&A transfer remove you from the waiting list, too? A3: I think that depends on how the M&A is justified. If you acquire a company that is already efficiently utilizing all its IP space, I don't think that would count toward fulfilling an outstanding need that you have a request on the waiting list for. However, if your justification for keeping the space held by the acquired company is that you plan to use it for new stuff, then that would meet an outstanding need, and a request for that same need would be considered fulfilled and removed from the waiting list. Q4: What about Multiple Discrete Networks? A4: Allocations and assignments to organizations using the Multiple Discrete Networks policy must still be made as a single continuous range of addresses. This preserves future aggregatability of the space, and ensures fairness between MDN and ordinary requests. Timetable for implementation: Immediate. ##### STAFF ASSESSMENT Proposal: Waiting List for Unmet IPv4 Requests Proposal Version: Updated by AC and given to staff for assessment on 29 Dec 2009 Date of Assessment: 12 January 2010 1. Proposal Summary (Staff Understanding) Staff understands that this proposal would create a waiting list for requestors whose IPv4 address needs cannot be fulfilled by ARIN at the time of the request approval. The proposal includes text to prevent requestors from gaming the policy's intent by forbidding requestors from making multiple requests of a small size and limiting the issuance of space to no more than once every 3 months. 2. Comments A. ARIN Staff Comments ? In section 4.1.8, the author says ?Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document an unforeseen change in circumstances since their last request?. As written, the portion of the policy that starts with ?but ARIN, at its sole discretion? gives no concrete criteria for staff to use in its assessment of the request. This ?exception clause? is open to interpretation and may not be applied consistently by staff if there are no guidelines or rules for staff to follow. It essentially allows ARIN staff to determine the policy criteria for who can or can?t qualify under this waiver. B. ARIN General Counsel "At this time counsel has no significant legal comments. Any system to order and prioritize requests for resources which may exceed the available resources must permit consistent administration by ARIN." 3. Resource Impact This policy would have moderate resource impact. It is estimated that implementation would occur within 6 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? The development of software to monitor IPv4 returns, a ?waiting list? that will include request size as well as minimum size acceptable, and a system that will match/compare returns with the waiting list ? Modifications to the management web application ? Changes to current business processes ? Updated guidelines ? Staff training 4. Proposal Text: Waiting list for unmet IPv4 requests Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN attempts to issue blocks of addresses on appropriate "CIDR-supported" bit boundaries. As long as sufficient space is available, ARIN may reserve space to maximize aggregation possibilities. ARIN will make each allocation and assignment as a single continuous range of addresses. Add new section 4.1.8: 4.1.8 Unmet requests In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to either modify their request and request a smaller size block, or be placed on a waiting list of pre-qualified recipients. Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document an unforeseen change in circumstances since their last request. Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. 4.1.8.1 Waiting list The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. 4.1.8.2 Fulfilling unmet needs As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. Rationale: ARIN will soon be unable to meet all approved requests for IPv4 address space. In the absence of a policy like this, it is unclear what ARIN should do with subsequent requests. This policy would allocate reclaimed address blocks (and the last of the ARIN free pool) on a first-come-first-served basis, while preserving aggregation to the degree possible. As the free pool shrinks, requests larger than the largest block left would be placed on a waiting list, while smaller requests would use up the rest of it, until all requests have to go on the waiting list. As additional reclaimed addresses become available, the requests that have been waiting the longest would be met first. If a requester gets the addresses they need via transfer, then they would be removed from the waiting list and would need to wait and submit a new request for additional address space, either directly or via transfer. FAQ: Q1: The effect of 2009-8, if implemented by the Board, is to allow transfers to be up to a 12 month supply of resources and up to a 3 month supply for resource from the ARIN free pool. Does that jive with your intent for this policy? A1: Correct. After we get to the last /8, you can request up to a 3-month supply from the free pool, but only every 3 months unless you can document an unforeseen change in circumstances since your last request. However, if you get the space via transfer, you can get a block big enough for 12 month's need, and if you end up using it up faster, you can submit another request after 3 months. Q2: If I were on the waiting list, and subsequently received a transfer via 8.3, would I be removed from the waiting list? A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer will be considered fulfilled and removed from the waiting list." Q3: Would receipt of an M&A transfer remove you from the waiting list, too? A3: I think that depends on how the M&A is justified. If you acquire a company that is already efficiently utilizing all its IP space, I don't think that would count toward fulfilling an outstanding need that you have a request on the waiting list for. However, if your justification for keeping the space held by the acquired company is that you plan to use it for new stuff, then that would meet an outstanding need, and a request for that same need would be considered fulfilled and removed from the waiting list. Q4: What about Multiple Discrete Networks? A4: Allocations and assignments to organizations using the Multiple Discrete Networks policy must still be made as a single continuous range of addresses. This preserves future aggregatability of the space, and ensures fairness between MDN and ordinary requests. From info at arin.net Thu Jan 21 14:47:26 2010 From: info at arin.net (Member Services) Date: Thu, 21 Jan 2010 14:47:26 -0500 Subject: [arin-ppml] Draft Policy 2010-2: Waiting List for Unmet IPv4 Requests Message-ID: <4B58AF4E.2000208@arin.net> Draft Policy 2010-2 Waiting List for Unmet IPv4 Requests On 15 January 2010 the ARIN Advisory Council (AC) selected "/24 End User Minimum Assignment Unit" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Toronto in April. The draft was developed by the AC from Policy Proposal "99. /24 End User Minimum Assignment Unit". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. The AC subsequently revised the text as follows: "Summary of changes: 1. Removed last sentence of section 4.3.2.2, per staff recommendation. 2. Added "4.3" to section 4.3.6.2 resulting in "...return all existing 4.3 assignments...", per staff recommendation. 3. Change title for section 4.3.6.2, per staff recommendation." Below the draft policy is the ARIN staff and legal assessment, including the original proposal text. Draft Policy 2010-2 is below and can be found at: https://www.arin.net/policy/proposals/2010_2.html You are encouraged to discuss Draft Policy 2010-2 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-2 24 End User Minimum Assignment Unit Version/Date: 21 January 2010 Policy statement: Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Additional assignments for small multi-homers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing 4.3 assignments within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. Timetable for implementation: Immediate ##### STAFF ASSESSMENT Proposal: /24 End User Minimum Assignment Unit Proposal Version: Updated by AC and given to staff for assessment on 29 Dec 2009 Date of Assessment: 12 January 2010 1. Proposal Summary (Staff Understanding) ARIN staff understands this policy would lower the minimum assignment size for a multi-homed end-user to a /24. End-users who have assignments of less than /22 from ARIN can only qualify for additional space under this policy if they agree to renumber out of their previous assignment(s) and return that space to ARIN within 12 months. The standard 25% immediate/50% one-year utilization requirements would continue to apply. 2. Comments A. ARIN Staff Comments 1. The policy text uses inconsistent terminology when it refers to prefix sizes; it says ?blocks smaller than /24? and ?when prefixes are assigned which are longer than /20?. The terminology should be adjusted so that it uses the same terminology for cidr prefixes consistently throughout the policy. 2. The criteria as stated in 4.3.6.2 are unclear, particularly in relation to end users who have previous address space from ARIN. Staff suggests that the author make the following changes for clarification purposes: ? Remove the last sentence of 4.3.2.2 that starts with ?End-users may not?. ? In section 4.3.6.2, insert the section number 4.3 so that it now reads, ?unless they agree to return all existing 4.3 assignments within 12 months?. This will make it clearer that only existing assignments from ARIN issued under the end user policy (NRPM 4.3) are to be returned. 3. The title of section 4.3.6.2 ?Replacement Assignments for Small Multihomers? would be clearer if it were changed to ?Additional Assignments for Small Multihomers?. This section specifically deals with small multihomers who want additional space and agree to return existing space. The requirement to return space is already detailed within the policy text. This title would also be more consistent with the existing style and terminology used in NRPM. B. ARIN General Counsel ?This policy poses no significant legal issues that need to be considered?. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Changes to guidelines ? Staff training Proposal Text: /24 End User Minimum Assignment Unit Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. End-users may not receive a block smaller than /22 under this policy if they already have IPv4 resources from ARIN, except as specified in section 4.3.6.2. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Replacement assignments for small multi-homers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing assignments within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. From jcurran at arin.net Thu Jan 21 14:57:37 2010 From: jcurran at arin.net (John Curran) Date: Thu, 21 Jan 2010 14:57:37 -0500 Subject: [arin-ppml] Joe Baptista Message-ID: <4AC3BBAA-7421-4F15-884D-FBAF87155FA4@arin.net> Acting on the recommendation of the ARIN Mailing List AUP Committee, Joe Baptista has been sent formal notice to cease violations of the ARIN Mailing List AUP on ARIN's mailing lists, and that any additional posting in violation of the AUP may result in sanctions including the immediate loss of his posting privileges to ARIN's mailing lists. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Thu Jan 21 15:02:08 2010 From: bill at herrin.us (William Herrin) Date: Thu, 21 Jan 2010 15:02:08 -0500 Subject: [arin-ppml] Draft Policy 2010-2: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B58AF4E.2000208@arin.net> References: <4B58AF4E.2000208@arin.net> Message-ID: <3c3e3fca1001211202i1771009dj5fff6f2e3980bfef@mail.gmail.com> On Thu, Jan 21, 2010 at 2:47 PM, Member Services wrote: > Any end-user that possesses an assignment smaller than /22 under any > part of section 4.3 shall not be able to get an additional assignment > unless they agree to return all existing 4.3 assignments within 12 > months of receiving a new assignment. This text is ripe for unintended consequences. Suggest this addition: Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing 4.3 assignments [smaller than /22] within 12 months of receiving a new assignment. Unless it's the AC's intention that companies like IBM or Oracle renumber their entire network simply because they happen to have picked up a /23 somewhere? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From steve at ibctech.ca Thu Jan 21 15:59:48 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 21 Jan 2010 15:59:48 -0500 Subject: [arin-ppml] Draft Policy 2010-2: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B58AF4E.2000208@arin.net> References: <4B58AF4E.2000208@arin.net> Message-ID: <4B58C044.8060206@ibctech.ca> Member Services wrote: > Draft Policy 2010-2 > Waiting List for Unmet IPv4 Requests Is it fair to assume that the subject line declaring this draft as "Waiting List for Unmet IPv4 Requests" is incorrect, and should actually be titled "Draft Policy 2010-2 /24 End User Minimum Assignment Unit"? I just finished reading 2010-1, and unless I'm overlooking something, the summary of changes in this message didn't seem right ;) Steve From info at arin.net Thu Jan 21 16:18:29 2010 From: info at arin.net (Member Services) Date: Thu, 21 Jan 2010 16:18:29 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title Message-ID: <4B58C4A5.2000406@arin.net> **Apologies - resending with correct title** Draft Policy 2010-2 /24 End User Minimum Assignment Unit On 15 January 2010 the ARIN Advisory Council (AC) selected "/24 End User Minimum Assignment Unit" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Toronto in April. The draft was developed by the AC from Policy Proposal "99. /24 End User Minimum Assignment Unit". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. The AC subsequently revised the text as follows: "Summary of changes: 1. Removed last sentence of section 4.3.2.2, per staff recommendation. 2. Added "4.3" to section 4.3.6.2 resulting in "...return all existing 4.3 assignments...", per staff recommendation. 3. Change title for section 4.3.6.2, per staff recommendation." Below the draft policy is the ARIN staff and legal assessment, including the original proposal text. Draft Policy 2010-2 is below and can be found at: https://www.arin.net/policy/proposals/2010_2.html You are encouraged to discuss Draft Policy 2010-2 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-2 24 End User Minimum Assignment Unit Version/Date: 21 January 2010 Policy statement: Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Additional assignments for small multi-homers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing 4.3 assignments within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. Timetable for implementation: Immediate ##### STAFF ASSESSMENT Proposal: /24 End User Minimum Assignment Unit Proposal Version: Updated by AC and given to staff for assessment on 29 Dec 2009 Date of Assessment: 12 January 2010 1. Proposal Summary (Staff Understanding) ARIN staff understands this policy would lower the minimum assignment size for a multi-homed end-user to a /24. End-users who have assignments of less than /22 from ARIN can only qualify for additional space under this policy if they agree to renumber out of their previous assignment(s) and return that space to ARIN within 12 months. The standard 25% immediate/50% one-year utilization requirements would continue to apply. 2. Comments A. ARIN Staff Comments 1. The policy text uses inconsistent terminology when it refers to prefix sizes; it says ?blocks smaller than /24? and ?when prefixes are assigned which are longer than /20?. The terminology should be adjusted so that it uses the same terminology for cidr prefixes consistently throughout the policy. 2. The criteria as stated in 4.3.6.2 are unclear, particularly in relation to end users who have previous address space from ARIN. Staff suggests that the author make the following changes for clarification purposes: ? Remove the last sentence of 4.3.2.2 that starts with ?End-users may not?. ? In section 4.3.6.2, insert the section number 4.3 so that it now reads, ?unless they agree to return all existing 4.3 assignments within 12 months?. This will make it clearer that only existing assignments from ARIN issued under the end user policy (NRPM 4.3) are to be returned. 3. The title of section 4.3.6.2 ?Replacement Assignments for Small Multihomers? would be clearer if it were changed to ?Additional Assignments for Small Multihomers?. This section specifically deals with small multihomers who want additional space and agree to return existing space. The requirement to return space is already detailed within the policy text. This title would also be more consistent with the existing style and terminology used in NRPM. B. ARIN General Counsel ?This policy poses no significant legal issues that need to be considered?. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Changes to guidelines ? Staff training Proposal Text: /24 End User Minimum Assignment Unit Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. End-users may not receive a block smaller than /22 under this policy if they already have IPv4 resources from ARIN, except as specified in section 4.3.6.2. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Replacement assignments for small multi-homers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing assignments within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. From dylan.ebner at crlmed.com Thu Jan 21 16:35:17 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Thu, 21 Jan 2010 21:35:17 +0000 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <4B58C4A5.2000406@arin.net> References: <4B58C4A5.2000406@arin.net> Message-ID: <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> Please correct me if I am interpreting this wrong. I am reading this as saying this policy will now allow multi-homed users to acquire a /24 or /23 from ARIN. Does this supersede the /22 minimum requirement for all end-users today or only apply to multi-homed end-users, i.e., non multi-homed will still need to apply for /22s? What if a user is already multi-homed, can they still apply for a /24 or /23? If I could get a /23 or /24 I would be in heaven. We are multi-homed today behind 2 ISPs and we have to get our /24s from our ISP's ip space. That makes a lot of hoops to jump through to get another ISP to advertise a competing ISPs space. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Thursday, January 21, 2010 3:18 PM To: arin ppml Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title **Apologies - resending with correct title** Draft Policy 2010-2 /24 End User Minimum Assignment Unit On 15 January 2010 the ARIN Advisory Council (AC) selected "/24 End User Minimum Assignment Unit" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Toronto in April. The draft was developed by the AC from Policy Proposal "99. /24 End User Minimum Assignment Unit". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. The AC subsequently revised the text as follows: "Summary of changes: 1. Removed last sentence of section 4.3.2.2, per staff recommendation. 2. Added "4.3" to section 4.3.6.2 resulting in "...return all existing 4.3 assignments...", per staff recommendation. 3. Change title for section 4.3.6.2, per staff recommendation." Below the draft policy is the ARIN staff and legal assessment, including the original proposal text. Draft Policy 2010-2 is below and can be found at: https://www.arin.net/policy/proposals/2010_2.html You are encouraged to discuss Draft Policy 2010-2 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-2 24 End User Minimum Assignment Unit Version/Date: 21 January 2010 Policy statement: Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Additional assignments for small multi-homers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing 4.3 assignments within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. Timetable for implementation: Immediate ##### STAFF ASSESSMENT Proposal: /24 End User Minimum Assignment Unit Proposal Version: Updated by AC and given to staff for assessment on 29 Dec 2009 Date of Assessment: 12 January 2010 1. Proposal Summary (Staff Understanding) ARIN staff understands this policy would lower the minimum assignment size for a multi-homed end-user to a /24. End-users who have assignments of less than /22 from ARIN can only qualify for additional space under this policy if they agree to renumber out of their previous assignment(s) and return that space to ARIN within 12 months. The standard 25% immediate/50% one-year utilization requirements would continue to apply. 2. Comments A. ARIN Staff Comments 1. The policy text uses inconsistent terminology when it refers to prefix sizes; it says "blocks smaller than /24" and "when prefixes are assigned which are longer than /20". The terminology should be adjusted so that it uses the same terminology for cidr prefixes consistently throughout the policy. 2. The criteria as stated in 4.3.6.2 are unclear, particularly in relation to end users who have previous address space from ARIN. Staff suggests that the author make the following changes for clarification purposes: * Remove the last sentence of 4.3.2.2 that starts with "End-users may not". * In section 4.3.6.2, insert the section number 4.3 so that it now reads, "unless they agree to return all existing 4.3 assignments within 12 months". This will make it clearer that only existing assignments from ARIN issued under the end user policy (NRPM 4.3) are to be returned. 3. The title of section 4.3.6.2 "Replacement Assignments for Small Multihomers" would be clearer if it were changed to "Additional Assignments for Small Multihomers". This section specifically deals with small multihomers who want additional space and agree to return existing space. The requirement to return space is already detailed within the policy text. This title would also be more consistent with the existing style and terminology used in NRPM. B. ARIN General Counsel "This policy poses no significant legal issues that need to be considered". 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Changes to guidelines * Staff training Proposal Text: /24 End User Minimum Assignment Unit Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. End-users may not receive a block smaller than /22 under this policy if they already have IPv4 resources from ARIN, except as specified in section 4.3.6.2. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Replacement assignments for small multi-homers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing assignments within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. _______________________________________________ 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 Jan 21 16:43:43 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Jan 2010 13:43:43 -0800 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> Message-ID: On Jan 21, 2010, at 1:35 PM, Dylan Ebner wrote: > Please correct me if I am interpreting this wrong. I am reading this as saying this policy will now allow multi-homed users to acquire a /24 or /23 from ARIN. Does this supersede the /22 minimum requirement for all end-users today or only apply to multi-homed end-users, i.e., non multi-homed will still need to apply for /22s? What if a user is already multi-homed, can they still apply for a /24 or /23? > If I could get a /23 or /24 I would be in heaven. We are multi-homed today behind 2 ISPs and we have to get our /24s from our ISP's ip space. That makes a lot of hoops to jump through to get another ISP to advertise a competing ISPs space. > Today, non-multihomed still need to qualify for a /20 (NRPM 4.3.2.1). This policy does not seek to change anything for non-multihomed end users. So, in answer to your final question, you would be able to use this policy if it is adopted to get the space you need. Owen > > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Thursday, January 21, 2010 3:18 PM > To: arin ppml > Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title > > **Apologies - resending with correct title** > > > Draft Policy 2010-2 > /24 End User Minimum Assignment Unit > > On 15 January 2010 the ARIN Advisory Council (AC) selected "/24 End User > Minimum Assignment Unit" as a draft policy for adoption discussion on > the PPML and at the Public Policy Meeting in Toronto in April. > > The draft was developed by the AC from Policy Proposal "99. /24 End User > Minimum Assignment Unit". Per the Policy Development Process the AC > submitted text to ARIN for a staff and legal assessment prior to its > selection as a draft policy. The AC subsequently revised the text as > follows: > > "Summary of changes: > 1. Removed last sentence of section 4.3.2.2, per staff recommendation. > > 2. Added "4.3" to section 4.3.6.2 resulting in "...return all > existing 4.3 assignments...", per staff recommendation. > > 3. Change title for section 4.3.6.2, per staff recommendation." > > Below the draft policy is the ARIN staff and legal assessment, including > the original proposal text. > > Draft Policy 2010-2 is below and can be found at: > https://www.arin.net/policy/proposals/2010_2.html > > You are encouraged to discuss Draft Policy 2010-2 on the PPML prior to > the April Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2010-2 > 24 End User Minimum Assignment Unit > > Version/Date: 21 January 2010 > Policy statement: > > Replace section 4.3.2.2 of the NRPM with the following: > > 4.3.2.2 Multihomed Connection > > For multi-homed end-users who demonstrate an intent to announce the > requested space in a multihomed fashion to two or more distinct ASNs not > owned or controlled by the end-user, the minimum block of IP address > space assigned is a /24. If assignments smaller than a /24 are needed, > multihomed end-users should contact their upstream providers. When > prefixes are assigned which are longer than /20, they will be from a > block reserved for that purpose so long as that is feasible. > > Renumber the existing paragraph under the 4.3.6 to > > 4.3.6.1 Utilization requirements for additional Assignment > > Add the following paragraph 4.3.6.2 > > 4.3.6.2 Additional assignments for small multi-homers > > Any end-user that possesses an assignment smaller than /22 under any > part of section 4.3 shall not be able to get an additional assignment > unless they agree to return all existing 4.3 assignments within 12 > months of receiving a new assignment. The new assignment shall be sized > to accommodate their existing utilization in addition to their justified > additional growth space under section 4.3.6.1. The common cases for this > are expected to be a /24 returned after receipt of a /23, or a /23 > returned after receipt of a /22. > > Rationale: > > This policy attempts to incorporate the recent and historical > discussions of policy for multi-home users on PPML. The intent is to > provide as fair a process as possible for multi-homed organizations down > to the smallest feasible size while still preserving some control over > growth in the routing table. > > It has been repeatedly noted that /24 multi-homers exist today with PA > space and still occupy a routing table slot, so, it is unlikely that > moving this boundary to /24 would significantly impact the routing table. > > By requiring smaller assignments to renumber and return, rather than add > more small blocks to their assignments, this policy seeks to further > reduce the chances of unnecessary growth in the routing table and > encourage good aggregation where possible. > > Does this apply only to end users? Yes, this policy applies only to end > users. This policy does not represent a good solution for organizations > that are delegating space to other entities. If a case can be made that > such a policy is needed for ISPs, then, the author is happy to work with > interested parties to craft such a policy, but, this policy would be > unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat > onerous to their peers and/or upstream providers. > > What about resources obtained from policies other than 4.3 or outside of > ARIN? Such resources would not be counted for excluding an organization > from this policy. The intent is to limit IPv4 micro-allocations for > multi-homed end-user organizations under this policy to a single > assignment unless each such assignment is /22 or larger. This is to > prevent unnecessary routing table growth. This is a tradeoff, and, not > the ideal solution for smaller end-user organizations, however, author > believes that this is the best policy likely to gain consensus at this > time and believes that it is incrementally far better for such > organizations than current policy. > > If I grow, I have to renumber? Not necessarily... If you have a /24 > under this policy, and you want to grow that, then, you will likely need > to renumber. Depending on ARIN resource management and timing, ARIN may > simply be able to give you the /23 that includes your /24. More likely, > you will get a new /23, have 1 year to renumber into that and return > your /24. At most, you would be subject to two such renumbering cycles > under this policy (24->23 and 23->22) before you meet the criteria for > other policies which do not require renumbering. > > Other policies don't include renumbering provisions, why this one? The > policy which allows multi-homed organizations to get a /22 was > originally written at /24. That policy was shouted down and /22 was the > compromise achieved to gain community consensus for anything smaller > than /20. Author hopes that this compromise will allow many > organizations to get resources they need with minimal impact while > assuring the community that doing so will not cause an explosion in the > routing table. > > Timetable for implementation: Immediate > > > ##### > > > STAFF ASSESSMENT > > Proposal: /24 End User Minimum Assignment Unit > > Proposal Version: Updated by AC and given to staff for assessment on 29 > Dec 2009 > > Date of Assessment: 12 January 2010 > > 1. Proposal Summary (Staff Understanding) > > ARIN staff understands this policy would lower the minimum assignment > size for a multi-homed end-user to a /24. End-users who have assignments > of less than /22 from ARIN can only qualify for additional space under > this policy if they agree to renumber out of their previous > assignment(s) and return that space to ARIN within 12 months. The > standard 25% immediate/50% one-year utilization requirements would > continue to apply. > > 2. Comments > > A. ARIN Staff Comments > > 1. The policy text uses inconsistent terminology when it refers to > prefix sizes; it says "blocks smaller than /24" and "when prefixes are > assigned which are longer than /20". The terminology should be adjusted > so that it uses the same terminology for cidr prefixes consistently > throughout the policy. > 2. The criteria as stated in 4.3.6.2 are unclear, particularly in > relation to end users who have previous address space from ARIN. Staff > suggests that the author make the following changes for clarification > purposes: > * Remove the last sentence of 4.3.2.2 that starts with "End-users may not". > * In section 4.3.6.2, insert the section number 4.3 so that it now > reads, "unless they agree to return all existing 4.3 assignments within > 12 months". This will make it clearer that only existing assignments > from ARIN issued under the end user policy (NRPM 4.3) are to be returned. > 3. The title of section 4.3.6.2 "Replacement Assignments for Small > Multihomers" would be clearer if it were changed to "Additional > Assignments for Small Multihomers". This section specifically deals > with small multihomers who want additional space and agree to return > existing space. The requirement to return space is already detailed > within the policy text. This title would also be more consistent with > the existing style and terminology used in NRPM. > > > B. ARIN General Counsel > > "This policy poses no significant legal issues that need to be > considered". > > 3. Resource Impact > > This policy would have minimal resource impact. It is estimated that > implementation would occur within 3 months after ratification by the > ARIN Board of Trustees. The following would be needed in order to > implement: > > * Changes to guidelines > * Staff training > > Proposal Text: /24 End User Minimum Assignment Unit > > Replace section 4.3.2.2 of the NRPM with the following: > > 4.3.2.2 Multihomed Connection > For multi-homed end-users who demonstrate an intent to announce the > requested space in a multihomed fashion to two or more distinct ASNs not > owned or controlled by the end-user, the minimum block of IP address > space assigned is a /24. If assignments smaller than a /24 are needed, > multihomed end-users should contact their upstream providers. When > prefixes are assigned which are longer than /20, they will be from a > block reserved for that purpose so long as that is feasible. End-users > may not receive a block smaller than /22 under this policy if they > already have IPv4 resources from ARIN, except as specified in section > 4.3.6.2. > > Renumber the existing paragraph under the 4.3.6 to > 4.3.6.1 Utilization requirements for additional Assignment > > Add the following paragraph 4.3.6.2 > > 4.3.6.2 Replacement assignments for small multi-homers > Any end-user that possesses an assignment smaller than /22 under any > part of section 4.3 shall not be able to get an additional assignment > unless they agree to return all existing assignments within 12 months of > receiving a new assignment. The new assignment shall be sized to > accommodate their existing utilization in addition to their justified > additional growth space under section 4.3.6.1. The common cases for this > are expected to be a /24 returned after receipt of a /23, or a /23 > returned after receipt of a /22. > > Rationale: > This policy attempts to incorporate the recent and historical > discussions of policy for multi-home users on PPML. The intent is to > provide as fair a process as possible for multi-homed organizations down > to the smallest feasible size while still preserving some control over > growth in the routing table. > It has been repeatedly noted that /24 multi-homers exist today with PA > space and still occupy a routing table slot, so, it is unlikely that > moving this boundary to /24 would significantly impact the routing table. > > By requiring smaller assignments to renumber and return, rather than add > more small blocks to their assignments, this policy seeks to further > reduce the chances of unnecessary growth in the routing table and > encourage good aggregation where possible. > Does this apply only to end users? Yes, this policy applies only to end > users. This policy does not represent a good solution for organizations > that are delegating space to other entities. If a case can be made that > such a policy is needed for ISPs, then, the author is happy to work with > interested parties to craft such a policy, but, this policy would be > unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat > onerous to their peers and/or upstream providers. > > What about resources obtained from policies other than 4.3 or outside of > ARIN? Such resources would not be counted for excluding an organization > from this policy. The intent is to limit IPv4 micro-allocations for > multi-homed end-user organizations under this policy to a single > assignment unless each such assignment is /22 or larger. This is to > prevent unnecessary routing table growth. This is a tradeoff, and, not > the ideal solution for smaller end-user organizations, however, author > believes that this is the best policy likely to gain consensus at this > time and believes that it is incrementally far better for such > organizations than current policy. > > If I grow, I have to renumber? Not necessarily... If you have a /24 > under this policy, and you want to grow that, then, you will likely need > to renumber. Depending on ARIN resource management and timing, ARIN may > simply be able to give you the /23 that includes your /24. More likely, > you will get a new /23, have 1 year to renumber into that and return > your /24. At most, you would be subject to two such renumbering cycles > under this policy (24->23 and 23->22) before you meet the criteria for > other policies which do not require renumbering. > > Other policies don't include renumbering provisions, why this one? The > policy which allows multi-homed organizations to get a /22 was > originally written at /24. That policy was shouted down and /22 was the > compromise achieved to gain community consensus for anything smaller > than /20. Author hopes that this compromise will allow many > organizations to get resources they need with minimal impact while > assuring the community that doing so will not cause an explosion in the > routing table. > > > > > > _______________________________________________ > 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 tedm at ipinc.net Thu Jan 21 17:20:14 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 21 Jan 2010 14:20:14 -0800 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> Message-ID: <4B58D31E.1090602@ipinc.net> Dylan Ebner wrote: > Please correct me if I am interpreting this wrong. I am reading this > as saying this policy will now allow multi-homed users to acquire a > /24 or /23 from ARIN. Does this supersede the /22 minimum requirement > for all end-users today or only apply to multi-homed end-users, i.e., > non multi-homed will still need to apply for /22s? What if a user is > already multi-homed, can they still apply for a /24 or /23? If I > could get a /23 or /24 I would be in heaven. We are multi-homed today > behind 2 ISPs and we have to get our /24s from our ISP's ip space. > That makes a lot of hoops to jump through to get another ISP to > advertise a competing ISPs space. > Dylan, For starters your mixing section 4.2 and 4.3 together. Section 4.2 only applies to ISP's who are reassigning IP numbers they get to downstream customers. Section 4.3 applies to corporations and businesses that don't reassign and use the numbers for their own purposes. That's an extremely important distinction to keep in mind. Secondly, if you can only justify a /23 then your actually better off "getting another ISP to advertise a competing ISP's space" than in attempting to get your own /23 or /24, even if this policy is approved. The reason why is that while your /23 or /24 would be a part of the DFZ, it would be so small in comparison to most of the blocks advertised on the Internet that there's a lot of networks (particularly running on routers with low ram in them) that will filter your /23 or /24 out entirely, and just default-route to one of their upstreams to cover the advertisements smaller than their filter break. It is a mistake to assume a /24 is globally visible in all routers on the Internet, if you spend some time working with different Looking Glasses (you can find a list on traceroute.org) you will quickly see that the smaller the advertisement the fewer routers it appears in. You may get suboptimal routing if you use a smaller block that is not part of a supernet, then if you use a small block that IS part of a supernet. Also, your going to quickly find that it's just as difficult to get a small portable block advertised from those "competing ISP's" as a small block that's assigned from an ISP. The real reason you should want a portable /24 or /23 is because you don't trust your upstream ISP's any further than you could spit a rat, and your worried that at some point they may pull them. For example, back in 2004, MCI pulled out of North America and all customers who had numbers assigned from them were forced to renumber - and they had quite a lot of ISP's as customers. If this is a concern then you should want your own numbers. But, if your just wanting them because you think it will be easier to get an upstream to advertise them, your going to be disappointed. Ted > > > Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 > Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. > 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com > > > -----Original Message----- From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Thursday, January 21, 2010 3:18 PM To: arin ppml Subject: > [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit > - Correct Title > > **Apologies - resending with correct title** > > > Draft Policy 2010-2 /24 End User Minimum Assignment Unit > > On 15 January 2010 the ARIN Advisory Council (AC) selected "/24 End > User Minimum Assignment Unit" as a draft policy for adoption > discussion on the PPML and at the Public Policy Meeting in Toronto in > April. > > The draft was developed by the AC from Policy Proposal "99. /24 End > User Minimum Assignment Unit". Per the Policy Development Process the > AC submitted text to ARIN for a staff and legal assessment prior to > its selection as a draft policy. The AC subsequently revised the text > as follows: > > "Summary of changes: 1. Removed last sentence of section 4.3.2.2, per > staff recommendation. > > 2. Added "4.3" to section 4.3.6.2 resulting in "...return all > existing 4.3 assignments...", per staff recommendation. > > 3. Change title for section 4.3.6.2, per staff recommendation." > > Below the draft policy is the ARIN staff and legal assessment, > including the original proposal text. > > Draft Policy 2010-2 is below and can be found at: > https://www.arin.net/policy/proposals/2010_2.html > > You are encouraged to discuss Draft Policy 2010-2 on the PPML prior > to the April Public Policy Meeting. Both the discussion on the list > and at the meeting will be used by the ARIN Advisory Council to > determine the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2010-2 24 End User Minimum Assignment Unit > > Version/Date: 21 January 2010 Policy statement: > > Replace section 4.3.2.2 of the NRPM with the following: > > 4.3.2.2 Multihomed Connection > > For multi-homed end-users who demonstrate an intent to announce the > requested space in a multihomed fashion to two or more distinct ASNs > not owned or controlled by the end-user, the minimum block of IP > address space assigned is a /24. If assignments smaller than a /24 > are needed, multihomed end-users should contact their upstream > providers. When prefixes are assigned which are longer than /20, they > will be from a block reserved for that purpose so long as that is > feasible. > > Renumber the existing paragraph under the 4.3.6 to > > 4.3.6.1 Utilization requirements for additional Assignment > > Add the following paragraph 4.3.6.2 > > 4.3.6.2 Additional assignments for small multi-homers > > Any end-user that possesses an assignment smaller than /22 under any > part of section 4.3 shall not be able to get an additional assignment > unless they agree to return all existing 4.3 assignments within 12 > months of receiving a new assignment. The new assignment shall be > sized to accommodate their existing utilization in addition to their > justified additional growth space under section 4.3.6.1. The common > cases for this are expected to be a /24 returned after receipt of a > /23, or a /23 returned after receipt of a /22. > > Rationale: > > This policy attempts to incorporate the recent and historical > discussions of policy for multi-home users on PPML. The intent is to > provide as fair a process as possible for multi-homed organizations > down to the smallest feasible size while still preserving some > control over growth in the routing table. > > It has been repeatedly noted that /24 multi-homers exist today with > PA space and still occupy a routing table slot, so, it is unlikely > that moving this boundary to /24 would significantly impact the > routing table. > > By requiring smaller assignments to renumber and return, rather than > add more small blocks to their assignments, this policy seeks to > further reduce the chances of unnecessary growth in the routing table > and encourage good aggregation where possible. > > Does this apply only to end users? Yes, this policy applies only to > end users. This policy does not represent a good solution for > organizations that are delegating space to other entities. If a case > can be made that such a policy is needed for ISPs, then, the author > is happy to work with interested parties to craft such a policy, but, > this policy would be unnecessarily onerous on ISPs, and, as an ISP > policy could be somewhat onerous to their peers and/or upstream > providers. > > What about resources obtained from policies other than 4.3 or outside > of ARIN? Such resources would not be counted for excluding an > organization from this policy. The intent is to limit IPv4 > micro-allocations for multi-homed end-user organizations under this > policy to a single assignment unless each such assignment is /22 or > larger. This is to prevent unnecessary routing table growth. This is > a tradeoff, and, not the ideal solution for smaller end-user > organizations, however, author believes that this is the best policy > likely to gain consensus at this time and believes that it is > incrementally far better for such organizations than current policy. > > If I grow, I have to renumber? Not necessarily... If you have a /24 > under this policy, and you want to grow that, then, you will likely > need to renumber. Depending on ARIN resource management and timing, > ARIN may simply be able to give you the /23 that includes your /24. > More likely, you will get a new /23, have 1 year to renumber into > that and return your /24. At most, you would be subject to two such > renumbering cycles under this policy (24->23 and 23->22) before you > meet the criteria for other policies which do not require > renumbering. > > Other policies don't include renumbering provisions, why this one? > The policy which allows multi-homed organizations to get a /22 was > originally written at /24. That policy was shouted down and /22 was > the compromise achieved to gain community consensus for anything > smaller than /20. Author hopes that this compromise will allow many > organizations to get resources they need with minimal impact while > assuring the community that doing so will not cause an explosion in > the routing table. > > Timetable for implementation: Immediate > > > ##### > > > STAFF ASSESSMENT > > Proposal: /24 End User Minimum Assignment Unit > > Proposal Version: Updated by AC and given to staff for assessment on > 29 Dec 2009 > > Date of Assessment: 12 January 2010 > > 1. Proposal Summary (Staff Understanding) > > ARIN staff understands this policy would lower the minimum assignment > size for a multi-homed end-user to a /24. End-users who have > assignments of less than /22 from ARIN can only qualify for > additional space under this policy if they agree to renumber out of > their previous assignment(s) and return that space to ARIN within 12 > months. The standard 25% immediate/50% one-year utilization > requirements would continue to apply. > > 2. Comments > > A. ARIN Staff Comments > > 1. The policy text uses inconsistent terminology when it refers to > prefix sizes; it says "blocks smaller than /24" and "when prefixes > are assigned which are longer than /20". The terminology should be > adjusted so that it uses the same terminology for cidr prefixes > consistently throughout the policy. 2. The criteria as stated in > 4.3.6.2 are unclear, particularly in relation to end users who have > previous address space from ARIN. Staff suggests that the author make > the following changes for clarification purposes: * Remove the last > sentence of 4.3.2.2 that starts with "End-users may not". * In > section 4.3.6.2, insert the section number 4.3 so that it now reads, > "unless they agree to return all existing 4.3 assignments within 12 > months". This will make it clearer that only existing assignments > from ARIN issued under the end user policy (NRPM 4.3) are to be > returned. 3. The title of section 4.3.6.2 "Replacement Assignments > for Small Multihomers" would be clearer if it were changed to > "Additional Assignments for Small Multihomers". This section > specifically deals with small multihomers who want additional space > and agree to return existing space. The requirement to return space > is already detailed within the policy text. This title would also be > more consistent with the existing style and terminology used in NRPM. > > > > B. ARIN General Counsel > > "This policy poses no significant legal issues that need to be > considered". > > 3. Resource Impact > > This policy would have minimal resource impact. It is estimated that > implementation would occur within 3 months after ratification by the > ARIN Board of Trustees. The following would be needed in order to > implement: > > * Changes to guidelines * Staff training > > Proposal Text: /24 End User Minimum Assignment Unit > > Replace section 4.3.2.2 of the NRPM with the following: > > 4.3.2.2 Multihomed Connection For multi-homed end-users who > demonstrate an intent to announce the requested space in a multihomed > fashion to two or more distinct ASNs not owned or controlled by the > end-user, the minimum block of IP address space assigned is a /24. If > assignments smaller than a /24 are needed, multihomed end-users > should contact their upstream providers. When prefixes are assigned > which are longer than /20, they will be from a block reserved for > that purpose so long as that is feasible. End-users may not receive a > block smaller than /22 under this policy if they already have IPv4 > resources from ARIN, except as specified in section 4.3.6.2. > > Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 > Utilization requirements for additional Assignment > > Add the following paragraph 4.3.6.2 > > 4.3.6.2 Replacement assignments for small multi-homers Any end-user > that possesses an assignment smaller than /22 under any part of > section 4.3 shall not be able to get an additional assignment unless > they agree to return all existing assignments within 12 months of > receiving a new assignment. The new assignment shall be sized to > accommodate their existing utilization in addition to their justified > additional growth space under section 4.3.6.1. The common cases for > this are expected to be a /24 returned after receipt of a /23, or a > /23 returned after receipt of a /22. > > Rationale: This policy attempts to incorporate the recent and > historical discussions of policy for multi-home users on PPML. The > intent is to provide as fair a process as possible for multi-homed > organizations down to the smallest feasible size while still > preserving some control over growth in the routing table. It has been > repeatedly noted that /24 multi-homers exist today with PA space and > still occupy a routing table slot, so, it is unlikely that moving > this boundary to /24 would significantly impact the routing table. > > By requiring smaller assignments to renumber and return, rather than > add more small blocks to their assignments, this policy seeks to > further reduce the chances of unnecessary growth in the routing table > and encourage good aggregation where possible. Does this apply only > to end users? Yes, this policy applies only to end users. This policy > does not represent a good solution for organizations that are > delegating space to other entities. If a case can be made that such a > policy is needed for ISPs, then, the author is happy to work with > interested parties to craft such a policy, but, this policy would be > unnecessarily onerous on ISPs, and, as an ISP policy could be > somewhat onerous to their peers and/or upstream providers. > > What about resources obtained from policies other than 4.3 or outside > of ARIN? Such resources would not be counted for excluding an > organization from this policy. The intent is to limit IPv4 > micro-allocations for multi-homed end-user organizations under this > policy to a single assignment unless each such assignment is /22 or > larger. This is to prevent unnecessary routing table growth. This is > a tradeoff, and, not the ideal solution for smaller end-user > organizations, however, author believes that this is the best policy > likely to gain consensus at this time and believes that it is > incrementally far better for such organizations than current policy. > > If I grow, I have to renumber? Not necessarily... If you have a /24 > under this policy, and you want to grow that, then, you will likely > need to renumber. Depending on ARIN resource management and timing, > ARIN may simply be able to give you the /23 that includes your /24. > More likely, you will get a new /23, have 1 year to renumber into > that and return your /24. At most, you would be subject to two such > renumbering cycles under this policy (24->23 and 23->22) before you > meet the criteria for other policies which do not require > renumbering. > > Other policies don't include renumbering provisions, why this one? > The policy which allows multi-homed organizations to get a /22 was > originally written at /24. That policy was shouted down and /22 was > the compromise achieved to gain community consensus for anything > smaller than /20. Author hopes that this compromise will allow many > organizations to get resources they need with minimal impact while > assuring the community that doing so will not cause an explosion in > the routing table. > > > > > > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. > > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From jcurran at arin.net Fri Jan 22 09:00:52 2010 From: jcurran at arin.net (John Curran) Date: Fri, 22 Jan 2010 09:00:52 -0500 Subject: [arin-ppml] Christopher Mettin Message-ID: <29849860-9CDD-48E4-9089-EF35A52F876B@arin.net> Acting on the recommendation of the ARIN Mailing List AUP Committee, Christopher Mettin has been banned from posting on ARIN mailing lists for a period of 6 months as a result of postings in violation of the AUP. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Jan 22 17:53:37 2010 From: bill at herrin.us (William Herrin) Date: Fri, 22 Jan 2010 17:53:37 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <4B58C4A5.2000406@arin.net> References: <4B58C4A5.2000406@arin.net> Message-ID: <3c3e3fca1001221453l2bd771bl6e4dd54bf8117a7b@mail.gmail.com> On Thu, Jan 21, 2010 at 4:18 PM, Member Services wrote: > 4.3.6.2 Additional assignments for small multi-homers > > Any end-user that possesses an assignment smaller than /22 under any > part of section 4.3 shall not be able to get an additional assignment > unless they agree to return all existing 4.3 assignments within 12 > months of receiving a new assignment. The new assignment shall be sized > to accommodate their existing utilization in addition to their justified > additional growth space under section 4.3.6.1. Abuse scenario: End user registrant holds two RSA /16's and a variety of legacy registrations including a legacy /24. He has sufficient utilization and projected growth to justify an additional /20. Registrant signs an RSA (not legacy RSA) for the /24 bringing it under the jurisdiction of the NRPM. Registrant requests additional resources. Registrant assigned a /14 (minimum CIDR block necessary to accommodate two /16's a /24 and a /20) and is required to return the two /16's and /24 within 12 months. Result: gaming the proposed policy nets the registrant 100,000 more IPv4 addresses than he would otherwise qualify for. Owen, I called your attention to the flaw in this text last week. I thought I pointed it out to you last August too but I could be mistaken. Either way, you really ought to fix it by constraining the return to just those assignments smaller than /22. I'd like to be able to support this proposal. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Jan 22 18:21:59 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 22 Jan 2010 15:21:59 -0800 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <3c3e3fca1001221453l2bd771bl6e4dd54bf8117a7b@mail.gmail.com> References: <4B58C4A5.2000406@arin.net> <3c3e3fca1001221453l2bd771bl6e4dd54bf8117a7b@mail.gmail.com> Message-ID: <26CCBB94-8B6F-432C-A14D-D4D1E85754A9@delong.com> On Jan 22, 2010, at 2:53 PM, William Herrin wrote: > On Thu, Jan 21, 2010 at 4:18 PM, Member Services wrote: >> 4.3.6.2 Additional assignments for small multi-homers >> >> Any end-user that possesses an assignment smaller than /22 under any >> part of section 4.3 shall not be able to get an additional assignment >> unless they agree to return all existing 4.3 assignments within 12 >> months of receiving a new assignment. The new assignment shall be sized >> to accommodate their existing utilization in addition to their justified >> additional growth space under section 4.3.6.1. > > Abuse scenario: > > End user registrant holds two RSA /16's and a variety of legacy > registrations including a legacy /24. He has sufficient utilization > and projected growth to justify an additional /20. > > Registrant signs an RSA (not legacy RSA) for the /24 bringing it under > the jurisdiction of the NRPM. > > Registrant requests additional resources. > > Registrant assigned a /14 (minimum CIDR block necessary to accommodate > two /16's a /24 and a /20) and is required to return the two /16's and > /24 within 12 months. > > Result: gaming the proposed policy nets the registrant 100,000 more > IPv4 addresses than he would otherwise qualify for. The existing policy under 4.7 allows them to do that without requiring gaming this policy, so, I am not sure why that is viewed as a problem with this policy. > > Owen, I called your attention to the flaw in this text last week. I > thought I pointed it out to you last August too but I could be > mistaken. Either way, you really ought to fix it by constraining the > return to just those assignments smaller than /22. > Yes, I saw your message last week, and, I'm considering ways to address that. However, I'm trying to avoid further unintended consequences in the process. Look for something shortly. > I'd like to be able to support this proposal. > That would be good. It's a no-op to the routing table and it's beneficial to a not insignificant class of registrants. Owen > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > 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 Fri Jan 22 18:40:16 2010 From: bill at herrin.us (William Herrin) Date: Fri, 22 Jan 2010 18:40:16 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <26CCBB94-8B6F-432C-A14D-D4D1E85754A9@delong.com> References: <4B58C4A5.2000406@arin.net> <3c3e3fca1001221453l2bd771bl6e4dd54bf8117a7b@mail.gmail.com> <26CCBB94-8B6F-432C-A14D-D4D1E85754A9@delong.com> Message-ID: <3c3e3fca1001221540t4ed9c2d7i3355ffddd38d4dc2@mail.gmail.com> On Fri, Jan 22, 2010 at 6:21 PM, Owen DeLong wrote: > Look for something shortly. Excellent. > On Jan 22, 2010, at 2:53 PM, William Herrin wrote: >> I'd like to be able to support this proposal. >> > That would be good. ?It's a no-op to the routing table and it's > beneficial to a not insignificant class of registrants. I think so too. I just want to be extra careful about any unintended side effects. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Fri Jan 22 18:47:00 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 22 Jan 2010 17:47:00 -0600 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <3c3e3fca1001221453l2bd771bl6e4dd54bf8117a7b@mail.gmail.com> References: <4B58C4A5.2000406@arin.net> <3c3e3fca1001221453l2bd771bl6e4dd54bf8117a7b@mail.gmail.com> Message-ID: <6eb799ab1001221547i1a0a2459pb5f03476d61b2551@mail.gmail.com> On Fri, Jan 22, 2010 at 4:53 PM, William Herrin wrote: > End user registrant holds two RSA /16's and a variety of legacy > registrations including a legacy /24. He has sufficient utilization > and projected growth to justify an additional /20. > Registrant signs an RSA (not legacy RSA) for the /24 bringing it under > the jurisdiction of the NRPM. > Registrant requests additional resources. > > Registrant assigned a /14 (minimum CIDR block necessary to accommodate > two /16's a /24 and a /20) and is required to return the two /16's and > /24 within 12 months. I suggest revising the text of the policy that says" The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. " To instead say: "The new assignment shall be sized to accommodate the lesser of the total address space they can justify under 4.3.3 and the combination of their existing utilization with their justified additional growth space under section 4.3.6.1. " In other words, that no matter what you return, the size of the address space you are assigned should not be greater than what you can justify under the utilization criterion. -- -J From farmer at umn.edu Sat Jan 23 02:28:57 2010 From: farmer at umn.edu (David Farmer) Date: Sat, 23 Jan 2010 01:28:57 -0600 Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment criteria - Updated text In-Reply-To: <4B4FA35F.9070804@arin.net> References: <4B4FA35F.9070804@arin.net> Message-ID: <4B5AA539.7000404@umn.edu> Here is some updated text including language allowing a /48 for each site of an organization with multiple sites and fixing the Community Network language. I have an outstanding question about how the community wants to deal with non-connected networks. But, I'm leaving the current language for now as it is most consistent with current policy. Feed back please. ---- Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: Rework of IPv6 assignment criteria 2. Proposal Originator a. name: David Farmer b. email: farmer at umn.edu c. telephone: 612-812-9952 d. organization: University of Minnesota 3. Proposal Version: 1.0 4. Date: 1/14/2010 5. Proposal type: modify new, modify, or delete. 6. Policy term: Permanent temporary, permanent, or renewable. 7. Policy statement: 6.5.8. Initial assignments 6.5.8.1. Initial assignment size Organizations that meet at least one of the following criteria are eligible to receive a minimum assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites and the number of subnets needed to support a site. Organizations with multiple sites are encouraged to consider the use /56 sub-assignments for smaller satellite sites. Not withstanding this, organizations may request a /48 for each site in their network, with the overall allocation rounded up to the next whole prefix as necessary. A subnet plan demonstrating a utilization of 33,689 or more subnets is necessary to justify an additional /48 for any individual site, beyond this the 0.94 HD-Ratio metric is used. All assignments shall be made from distinctly identified prefixes, with each assignment receiving a reservation for growth of at least a /44. Such reservations are not guaranteed and ARIN, at its discretion, may assign them to other organizations at any time. 6.5.8.2. Criteria for initial assignment to Internet connected end-users Organizations may justify an initial assignment for connecting their own network to the IPv6 Internet, with an intent to provide global reachability for the assignment within 12 months, and for addressing devices directly attached to their network infrastructure, by meeting one of the following additional criteria. a. Having a previously justified IPv4 end-users assignment from ARIN or one of its predecessor registries, or; b. Currently being Multihomed or immediately becoming Multihomed and using an assigned valid global AS number, or; c. By providing a reasonable technical justification indicating why other IPv6 addresses from an ISP or other LIR are unsuitable and a plan detailing the utilization of sites and subnets for one, two and five year periods. 6.5.8.3 Criteria for initial assignment to non-connected networks Organizations are encouraged to consider the use of Unique Local IPv6 Unicast Addresses (ULA, See RFC 4193) for a non-connected network. Not withstanding this, organizations may justify an initial assignment for operating their own non-connected IPv6 network and for addressing devices directly attached to their network infrastructure, by meeting one of the following additional criteria. a. Having a previously justified IPv4 end-users assignment from ARIN or one of its predecessor registries, or; b. By providing a reasonable technical justification indicating why an assignment for a non-connected networks is necessary, including the intended purpose for the assignment, and describing the network infrastructure the assignment will be used to support. Justification must include why ULA IPv6 addresses are unsuitable and a plan detailing the utilization of sites and subnets for one, two and five year periods. 6.5.8.4 Criteria for initial assignment to Community Networks Organizations may justify an initial assignment for operating a Community Network by documenting that they meet the criteria specified in section 2.11. A Community Network is considered a single site and a larger initial assignment may only be justified based on the number of subnets necessary to serve the community in question. 6.5.9. Subsequent assignments Subsequent assignments may be made when the need for additional sites or subnets are justified with reasonable supporting documentation. Organizations with multiple sites are encouraged to consider the use /56s for smaller satellite sites. Not withstanding this, organizations may request a /48 for each site, with the overall allocation rounded up to the next whole prefix as necessary. A subnet plan demonstrating a utilization of 33,689 or more subnets is necessary to justify an additional /48 for any individual site, beyond this the 0.94 HD-Ratio metric is used. When possible, subsequent assignments will be made from an adjacent address block. 8. Rationale: This proposal provides a complete rework of the IPv6 end-user assignment criteria, removing the dependency on IPv4 policy, while maintaining many of the basic concepts contained in the current policies. The order of the subsections of 6.5.8 was rearranged moving the initial assignment size to 6.5.8.1 and subsequent assignments to 6.5.9. This will facilitate adding future criteria without additional renumbering of current policies. The initial assignment criteria include the following general concepts; ? When Internet connectivity is use to justify resources it is implied the resources should be advertised to the Internet, within some reasonable time frame after they are received. ? IPv4 resources may be use to justify the need for IPv6 resources. ? Internet multihoming is sufficient justification for an end-user assignment in and of itself. ? Other Internet connected end-users must justify why an ISP or LIR assignment is not sufficient for their needs. ? Non-connected networks must describe the purpose and network infrastructure the assignment will be supporting, including why ULA is not sufficient for their needs. ? Organizations with multiple sites are allowed to request a /48 for each site, with a suggestion to use /56s for smaller sites. ? While HD-Ratio is not completely eliminated it really only applies to situations that an individual site of an organization needs more that a /48. ? Community networks are assumed to justify an assignment in and of themselves, but they should be considered a single site, otherwise they should get an ISP allocation. 9. Timetable for implementation: Immediate END OF TEMPLATE -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jim at tgasolutions.com Mon Jan 25 15:32:50 2010 From: jim at tgasolutions.com (Jim McBurnett) Date: Mon, 25 Jan 2010 15:32:50 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <4B58D31E.1090602@ipinc.net> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> Message-ID: >From Ted: >>> Secondly, if you can only justify a /23 then your actually better >>>off "getting another ISP to advertise a competing ISP's space" than >>>in attempting to get your own /23 or /24, even if this policy is >>>approved. The reason why is that while your /23 or /24 would be >>>a part of the DFZ, it would be so small in comparison to most of >>>the blocks advertised on the Internet that there's a lot of networks >>>(particularly running on routers with low ram in them) that will >>>filter your /23 or /24 out entirely, and just default-route to >>>one of their upstreams to cover the advertisements smaller than their >>>filter break. It is a mistake to assume a /24 is globally visible >>>in all routers on the Internet, if you spend some time working with >>>different Looking Glasses (you can find a list on traceroute.org) you >>>will quickly see that the smaller the advertisement the fewer routers >>>it appears in. You may get suboptimal routing if you use a >>>smaller block that is not part of a supernet, then if you use a >>>small block that IS part of a supernet. >>> >>> Also, your going to quickly find that it's just as difficult to >>>get a small portable block advertised from those "competing ISP's" >>>as a small block that's assigned from an ISP. >>> Please forgive the intrusion... I post rarely--- As a consultant, I have several customers that are multi-homed. Many have the issue of getting IP Space from an ISP. Some ISP's have to be read ARIN policy on the multi-home requirement To allow for a /24.. Granted some of these customers cannot truly justify a /24 for that site. HOWEVER-- there are concerns for them to do some other redundancy options.. Correct me if I am wrong-- But over on Cisco-NSP on Jared Mauch's site, I remember a conversation A few months ago covering the /24 filtering.. many thought it was only being done on old routers.. And someone went so far to say that it was only done when it was a lower tier edge from a small ISP. I think there was a branch on that thread that mentioned a default injection too.. But lots of water has Flowed under the bridge since then.... As it is written today, I believe it sounds reasonable... and actually have a few end users that would benefit. I am specifically addressing the small user, not the IBM as mentioned in the thread by Bill Herrin. He has a very valid point, IMHO... I know there are lots of folks here that members of the other RIR's lists.. so: My parting shots are this: What are the other RIR's doing? IF they are already doing this, why is ARIN not? IF they are not, what makes ARIN different? This is not to say, ARIN should emulate the other RIR's but their logic may discount or account for issue or non-issues we may see here... Thanks, Jim McBurnett From rudi.daniel at gmail.com Mon Jan 25 15:50:31 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Mon, 25 Jan 2010 16:50:31 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 55, Issue 41 In-Reply-To: References: Message-ID: <8aeeaff61001251250r3c5e1316ge2a291c8ed0c42ec@mail.gmail.com> Im having a little trouble with this proposal, -J's comment below warrants consideration in my understanding so far...however, im still not sure I fully understand the ramifications of such a proposal./ RD > In other words, that no matter what you return, the size of the > address space you are assigned should not be greater than what you > can justify under the utilization criterion. > > -- > -J > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jan 26 00:03:01 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Jan 2010 21:03:01 -0800 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> Message-ID: <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> On Jan 25, 2010, at 12:32 PM, Jim McBurnett wrote: >> From Ted: >>>> Secondly, if you can only justify a /23 then your actually better >>>> off "getting another ISP to advertise a competing ISP's space" than >>>> in attempting to get your own /23 or /24, even if this policy is >>>> approved. The reason why is that while your /23 or /24 would be >>>> a part of the DFZ, it would be so small in comparison to most of >>>> the blocks advertised on the Internet that there's a lot of networks >>>> (particularly running on routers with low ram in them) that will >>>> filter your /23 or /24 out entirely, and just default-route to >>>> one of their upstreams to cover the advertisements smaller than their >>>> filter break. It is a mistake to assume a /24 is globally visible >>>> in all routers on the Internet, if you spend some time working with >>>> different Looking Glasses (you can find a list on traceroute.org) you >>>> will quickly see that the smaller the advertisement the fewer routers >>>> it appears in. You may get suboptimal routing if you use a >>>> smaller block that is not part of a supernet, then if you use a >>>> small block that IS part of a supernet. >>>> >>>> Also, your going to quickly find that it's just as difficult to >>>> get a small portable block advertised from those "competing ISP's" >>>> as a small block that's assigned from an ISP. >>>> > > Please forgive the intrusion... I post rarely--- > > As a consultant, I have several customers that are multi-homed. Many have the issue of getting > IP Space from an ISP. Some ISP's have to be read ARIN policy on the multi-home requirement > To allow for a /24.. Granted some of these customers cannot truly justify a /24 for that site. > HOWEVER-- there are concerns for them to do some other redundancy options.. > > Correct me if I am wrong-- But over on Cisco-NSP on Jared Mauch's site, I remember a conversation > A few months ago covering the /24 filtering.. many thought it was only being done on old routers.. > And someone went so far to say that it was only done when it was a lower tier edge from a small ISP. > I think there was a branch on that thread that mentioned a default injection too.. But lots of water has > Flowed under the bridge since then.... > > As it is written today, I believe it sounds reasonable... and actually have a few end users that would benefit. > I am specifically addressing the small user, not the IBM as mentioned in the thread by Bill Herrin. > He has a very valid point, IMHO... > > > I know there are lots of folks here that members of the other RIR's lists.. so: > My parting shots are this: > What are the other RIR's doing? RIPE and APNIC will issue /24 and in some cases even smaller. I do not know for sure about AfriNIC (I think they go down to /24) or LACNIC. > IF they are already doing this, why is ARIN not? I think that's an excellent question. > IF they are not, what makes ARIN different? > This is not to say, ARIN should emulate the other RIR's but their logic may discount or account for issue or non-issues we may see here... > Thanks for your comments. I hope you will post more often and make your voice known at the public policy meeting, either in person, or, through remote participation. Owen From scottleibrand at gmail.com Tue Jan 26 22:55:25 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 26 Jan 2010 19:55:25 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B58AED5.4030705@arin.net> References: <4B58AED5.4030705@arin.net> Message-ID: <4B5FB92D.9060100@gmail.com> On 1/21/2010 11:45 AM, Member Services wrote: > > A. ARIN Staff Comments > > ? In section 4.1.8, the author says ?Repeated requests, in a manner that > would circumvent 4.1.6, are not allowed: an organization may only > receive one allocation, assignment, or transfer every 3 months, but > ARIN, at its sole discretion, may waive this requirement if the > requester can document an unforeseen change in circumstances since their > last request?. > > As written, the portion of the policy that starts with ?but ARIN, at its > sole discretion? gives no concrete criteria for staff to use in its > assessment of the request. This ?exception clause? is open to > interpretation and may not be applied consistently by staff if there are > no guidelines or rules for staff to follow. It essentially allows ARIN > staff to determine the policy criteria for who can or can?t qualify > under this waiver. To address this issue, I have added one more Q&A to the FAQ in the Rationale of this proposal: Q5: What would constitute "an unforeseen change in circumstances since their last request" that would allow ARIN to waive the 3-month delay to receive a second block? A5: This would, of course, be a matter of discretion for ARIN, but the idea here is that the burden of proof is on the requester to document some change in circumstances, that could not have been reasonably foreseen at the time of the original request, that now justifies additional space. This is intended to be a rarely used safety valve. Does anyone have any suggestions for a better way to address this? IMO we've already made the proposal text as specific as we can without dramatically increasing the complexity to address corner cases, etc. Of course, that may be simply a lack of imagination on my part, so ideas for alternate proposal text are welcome. Thanks, Scott From steve at ibctech.ca Tue Jan 26 23:48:17 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 26 Jan 2010 23:48:17 -0500 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B5FB92D.9060100@gmail.com> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> Message-ID: <4B5FC591.9000805@ibctech.ca> Scott Leibrand wrote: > On 1/21/2010 11:45 AM, Member Services wrote: >> >> A. ARIN Staff Comments >> >> ? In section 4.1.8, the author says ?Repeated requests, in a manner that >> would circumvent 4.1.6, are not allowed: an organization may only >> receive one allocation, assignment, or transfer every 3 months, but >> ARIN, at its sole discretion, may waive this requirement if the >> requester can document an unforeseen change in circumstances since their >> last request?. >> >> As written, the portion of the policy that starts with ?but ARIN, at its >> sole discretion? gives no concrete criteria for staff to use in its >> assessment of the request. This ?exception clause? is open to >> interpretation and may not be applied consistently by staff if there are >> no guidelines or rules for staff to follow. It essentially allows ARIN >> staff to determine the policy criteria for who can or can?t qualify >> under this waiver. > > To address this issue, I have added one more Q&A to the FAQ in the > Rationale of this proposal: > > Q5: What would constitute "an unforeseen change in circumstances since > their last request" that would allow ARIN to waive the 3-month delay to > receive a second block? > > A5: This would, of course, be a matter of discretion for ARIN, but the > idea here is that the burden of proof is on the requester to document > some change in circumstances, that could not have been reasonably > foreseen at the time of the original request, that now justifies > additional space. This is intended to be a rarely used safety valve. Given that this deals with runout, I'll take my first crack... all criticism very welcome (I'm bracing for it ;) A5: The use of this 'emergency safety valve' would have the burden of proof put upon the requester, as to force them to adequately document a significant change in circumstance. The requesters documentation would include information on their proper initial due diligence, and reasoning for not have been able to foresee such a situation at the time of the original request. Any and all requests that fall under this 'clause' category shall be presented to the ARIN PPML mailing list without any identifying information, other than the number of IP blocks that the requester has requested within the last 12 months, the number and size of IP blocks the requester has received within the last 18? months, and the [due diligence] documentation presented with the 'emergency' request. The blocks will be provided for distribution to the requester upon community consensus, following the same procedures of the PDP, but at [expedited pace] timeframe. Steve From scottleibrand at gmail.com Tue Jan 26 23:55:15 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 26 Jan 2010 20:55:15 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B5FC591.9000805@ibctech.ca> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> <4B5FC591.9000805@ibctech.ca> Message-ID: <4B5FC733.1010800@gmail.com> On 1/26/2010 8:48 PM, Steve Bertrand wrote: > Scott Leibrand wrote: > >> On 1/21/2010 11:45 AM, Member Services wrote: >> >>> A. ARIN Staff Comments >>> >>> ? In section 4.1.8, the author says ?Repeated requests, in a manner that >>> would circumvent 4.1.6, are not allowed: an organization may only >>> receive one allocation, assignment, or transfer every 3 months, but >>> ARIN, at its sole discretion, may waive this requirement if the >>> requester can document an unforeseen change in circumstances since their >>> last request?. >>> >>> As written, the portion of the policy that starts with ?but ARIN, at its >>> sole discretion? gives no concrete criteria for staff to use in its >>> assessment of the request. This ?exception clause? is open to >>> interpretation and may not be applied consistently by staff if there are >>> no guidelines or rules for staff to follow. It essentially allows ARIN >>> staff to determine the policy criteria for who can or can?t qualify >>> under this waiver. >>> >> To address this issue, I have added one more Q&A to the FAQ in the >> Rationale of this proposal: >> >> Q5: What would constitute "an unforeseen change in circumstances since >> their last request" that would allow ARIN to waive the 3-month delay to >> receive a second block? >> >> A5: This would, of course, be a matter of discretion for ARIN, but the >> idea here is that the burden of proof is on the requester to document >> some change in circumstances, that could not have been reasonably >> foreseen at the time of the original request, that now justifies >> additional space. This is intended to be a rarely used safety valve. >> > Given that this deals with runout, I'll take my first crack... all > criticism very welcome (I'm bracing for it ;) > Thanks: good feedback. > > A5: The use of this 'emergency safety valve' would have the burden of > proof put upon the requester, as to force them to adequately document a > significant change in circumstance. The requesters documentation would > include information on their proper initial due diligence, and reasoning > for not have been able to foresee such a situation at the time of the > original request. > I like this, and may steal some of your language. :-) > Any and all requests that fall under this 'clause' category shall be > presented to the ARIN PPML mailing list without any identifying > information, other than the number of IP blocks that the requester has > requested within the last 12 months, the number and size of IP blocks > the requester has received within the last 18? months, and the [due > diligence] documentation presented with the 'emergency' request. > > The blocks will be provided for distribution to the requester upon > community consensus, following the same procedures of the PDP, but at > [expedited pace] timeframe. > I'm not convinced that we want to inject PPML into the process in-line. Given that the current policy process cycle is about 6 months, I'm not sure if we could do an [expedited pace] that would actually be faster than waiting the 3 months... However, I definitely want to see transparency in how this policy is being used. We do have an existing mechanism for ARIN staff to report back to the community on how policies are working out: at every ARIN meeting staff (Leslie) gives a Policy Experience Report, detailing how one or more aspects of policy are actually working in practice, and suggesting changes where necessary. And, of course, she takes questions as well. So I'm thinking maybe we'd want to have staff report on the number of waivers requested and granted, and any interesting details of the circumstances surrounding the requests... Thoughts? Scott From steve at ibctech.ca Wed Jan 27 00:14:51 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Jan 2010 00:14:51 -0500 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B5FC591.9000805@ibctech.ca> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> <4B5FC591.9000805@ibctech.ca> Message-ID: <4B5FCBCB.5010808@ibctech.ca> Steve Bertrand wrote: > Scott Leibrand wrote: >> On 1/21/2010 11:45 AM, Member Services wrote: >>> A. ARIN Staff Comments >>> >>> ? In section 4.1.8, the author says ?Repeated requests, in a manner that >>> would circumvent 4.1.6, are not allowed: an organization may only >>> receive one allocation, assignment, or transfer every 3 months, but >>> ARIN, at its sole discretion, may waive this requirement if the >>> requester can document an unforeseen change in circumstances since their >>> last request?. >>> >>> As written, the portion of the policy that starts with ?but ARIN, at its >>> sole discretion? gives no concrete criteria for staff to use in its >>> assessment of the request. This ?exception clause? is open to >>> interpretation and may not be applied consistently by staff if there are >>> no guidelines or rules for staff to follow. It essentially allows ARIN >>> staff to determine the policy criteria for who can or can?t qualify >>> under this waiver. >> To address this issue, I have added one more Q&A to the FAQ in the >> Rationale of this proposal: >> >> Q5: What would constitute "an unforeseen change in circumstances since >> their last request" that would allow ARIN to waive the 3-month delay to >> receive a second block? >> >> A5: This would, of course, be a matter of discretion for ARIN, but the >> idea here is that the burden of proof is on the requester to document >> some change in circumstances, that could not have been reasonably >> foreseen at the time of the original request, that now justifies >> additional space. This is intended to be a rarely used safety valve. > > Given that this deals with runout, I'll take my first crack... all > criticism very welcome (I'm bracing for it ;) > > > A5: The use of this 'emergency safety valve' would have the burden of > proof put upon the requester, as to force them to adequately document a > significant change in circumstance. The requesters documentation would > include information on their proper initial due diligence, and reasoning > for not have been able to foresee such a situation at the time of the > original request. > > Any and all requests that fall under this 'clause' category shall be > presented to the ARIN PPML mailing list without any identifying > information, other than the number of IP blocks that the requester has > requested within the last 12 months, the number and size of IP blocks > the requester has received within the last 18? months, and the [due > diligence] documentation presented with the 'emergency' request. > > The blocks will be provided for distribution to the requester upon > community consensus, following the same procedures of the PDP, but at > [expedited pace] timeframe. This is all of course due to 'trusting' that the Internet community will vote yay/nay for the proper reasons, not for personal gain... My intention is solely to have community voting for distribution of space within the last few blocks for _whoops_ requests like this, without having the knowledge of who the the requester is. I don't like ARIN (or anybody) having "sole discretion", and I don't believe that anyone on the ARIN staff would admire having that responsibility either. Gaming is going to happen no matter what. The interesting stories of 2020 will be from the orgs who found their own survival methods, and hopefully of RIRs who had communities that found a fair way to divvy up the last piece of the pie. Steve From steve at ibctech.ca Wed Jan 27 01:27:34 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Jan 2010 01:27:34 -0500 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B5FC733.1010800@gmail.com> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> <4B5FC591.9000805@ibctech.ca> <4B5FC733.1010800@gmail.com> Message-ID: <4B5FDCD6.4000509@ibctech.ca> Scott Leibrand wrote: > On 1/26/2010 8:48 PM, Steve Bertrand wrote: >> Scott Leibrand wrote: >> >>> On 1/21/2010 11:45 AM, Member Services wrote: >>> >>>> A. ARIN Staff Comments >>>> >>>> ? In section 4.1.8, the author says ?Repeated requests, in a manner >>>> that >>>> would circumvent 4.1.6, are not allowed: an organization may only >>>> receive one allocation, assignment, or transfer every 3 months, but >>>> ARIN, at its sole discretion, may waive this requirement if the >>>> requester can document an unforeseen change in circumstances since >>>> their >>>> last request?. >>>> >>>> As written, the portion of the policy that starts with ?but ARIN, at >>>> its >>>> sole discretion? gives no concrete criteria for staff to use in its >>>> assessment of the request. This ?exception clause? is open to >>>> interpretation and may not be applied consistently by staff if there >>>> are >>>> no guidelines or rules for staff to follow. It essentially allows ARIN >>>> staff to determine the policy criteria for who can or can?t qualify >>>> under this waiver. >>>> >>> To address this issue, I have added one more Q&A to the FAQ in the >>> Rationale of this proposal: >>> >>> Q5: What would constitute "an unforeseen change in circumstances since >>> their last request" that would allow ARIN to waive the 3-month delay to >>> receive a second block? >>> >>> A5: This would, of course, be a matter of discretion for ARIN, but the >>> idea here is that the burden of proof is on the requester to document >>> some change in circumstances, that could not have been reasonably >>> foreseen at the time of the original request, that now justifies >>> additional space. This is intended to be a rarely used safety valve. >>> >> Given that this deals with runout, I'll take my first crack... all >> criticism very welcome (I'm bracing for it ;) >> > > Thanks: good feedback. > >> >> A5: The use of this 'emergency safety valve' would have the burden of >> proof put upon the requester, as to force them to adequately document a >> significant change in circumstance. The requesters documentation would >> include information on their proper initial due diligence, and reasoning >> for not have been able to foresee such a situation at the time of the >> original request. >> > > I like this, and may steal some of your language. :-) > >> Any and all requests that fall under this 'clause' category shall be >> presented to the ARIN PPML mailing list without any identifying >> information, other than the number of IP blocks that the requester has >> requested within the last 12 months, the number and size of IP blocks >> the requester has received within the last 18? months, and the [due >> diligence] documentation presented with the 'emergency' request. >> >> The blocks will be provided for distribution to the requester upon >> community consensus, following the same procedures of the PDP, but at >> [expedited pace] timeframe. >> > > I'm not convinced that we want to inject PPML into the process in-line. > Given that the current policy process cycle is about 6 months, I'm not > sure if we could do an [expedited pace] that would actually be faster > than waiting the 3 months... The way I see it, the only way to present something to the entire community is via the PPML. Unfortunately, I haven't found any method that ARIN staff is permitted to use that would allow them to expedite such information to the PPML, without "declaring an emergency". It would seem that over-using this portion of the PDP would cause the term 'emergency' to become useless, and also, would require a policy draft to be submitted, which is senseless regarding an IP request. Again however, as I understand (I've only read the PDP once-over, other than glancing here-and-there) (btw, the PDF Appendix A reflects nicely), the only way to present something for community consensus *is* via the PPML, _after_ it has gone through proper channels. Perhaps you're not convinced that a request for _whoops_ emergency requests should have to fall through the PPML due to the 'normal' process cycle, but could this [expedited pace] not be written into a community agreed-upon policy of some-sort that could bypass the first few PDP steps if it's been noted within an ARIN 'system' that it falls within this 'clause'? - passed directly to the AC (bypassing staff, clarity and understanding) - AC verifies, sends to PPML - 10 days on PPML (everyone is paying attention near runout ;) - community consensus, even if its 1-0 - BoT fiduciary - done, yay/nay... no recourse. The community said so. - apply again if necessary, but your same stats will be provided the next time around, otherwise, wait until you are out of the 'clause' window > However, I definitely want to see transparency in how this policy is > being used. We do have an existing mechanism for ARIN staff to report > back to the community on how policies are working out: at every ARIN > meeting staff (Leslie) gives a Policy Experience Report, detailing how > one or more aspects of policy are actually working in practice, and > suggesting changes where necessary. And, of course, she takes questions > as well. So I'm thinking maybe we'd want to have staff report on the > number of waivers requested and granted, and any interesting details of > the circumstances surrounding the requests... I'm going overboard on a finer point on your proposal. Hopefully I'll be at the next ARIN meeting to hear the Policy Experience Report. I do like the transparency of the process. I specifically like the fact that *anyone* can drum up ideas, throw them at the list, and see what happens. The transparency, and bottom-up approach seems to be quite effective (all the while spurring intriguing and very interesting dialogue). I'm more concerned whether your policy will ensure that *ALL* IPv6 addresses will fall under: "Each allocation/assignment size will be made out of separate blocks reserved for that purpose." however... Steve From scottleibrand at gmail.com Wed Jan 27 01:42:14 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 26 Jan 2010 22:42:14 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B5FDCD6.4000509@ibctech.ca> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> <4B5FC591.9000805@ibctech.ca> <4B5FC733.1010800@gmail.com> <4B5FDCD6.4000509@ibctech.ca> Message-ID: <4B5FE046.4050701@gmail.com> On 1/26/2010 10:27 PM, Steve Bertrand wrote: > Scott Leibrand wrote: > >> On 1/26/2010 8:48 PM, Steve Bertrand wrote: >> >>> Scott Leibrand wrote: >>> >>> >>>> On 1/21/2010 11:45 AM, Member Services wrote: >>>> >>>> >>>>> A. ARIN Staff Comments >>>>> >>>>> ? In section 4.1.8, the author says ?Repeated requests, in a manner >>>>> that >>>>> would circumvent 4.1.6, are not allowed: an organization may only >>>>> receive one allocation, assignment, or transfer every 3 months, but >>>>> ARIN, at its sole discretion, may waive this requirement if the >>>>> requester can document an unforeseen change in circumstances since >>>>> their >>>>> last request?. >>>>> >>>>> As written, the portion of the policy that starts with ?but ARIN, at >>>>> its >>>>> sole discretion? gives no concrete criteria for staff to use in its >>>>> assessment of the request. This ?exception clause? is open to >>>>> interpretation and may not be applied consistently by staff if there >>>>> are >>>>> no guidelines or rules for staff to follow. It essentially allows ARIN >>>>> staff to determine the policy criteria for who can or can?t qualify >>>>> under this waiver. >>>>> >>>>> >>>> To address this issue, I have added one more Q&A to the FAQ in the >>>> Rationale of this proposal: >>>> >>>> Q5: What would constitute "an unforeseen change in circumstances since >>>> their last request" that would allow ARIN to waive the 3-month delay to >>>> receive a second block? >>>> >>>> A5: This would, of course, be a matter of discretion for ARIN, but the >>>> idea here is that the burden of proof is on the requester to document >>>> some change in circumstances, that could not have been reasonably >>>> foreseen at the time of the original request, that now justifies >>>> additional space. This is intended to be a rarely used safety valve. >>>> >>>> >>> Given that this deals with runout, I'll take my first crack... all >>> criticism very welcome (I'm bracing for it ;) >>> >>> >> Thanks: good feedback. >> >> >>> A5: The use of this 'emergency safety valve' would have the burden of >>> proof put upon the requester, as to force them to adequately document a >>> significant change in circumstance. The requesters documentation would >>> include information on their proper initial due diligence, and reasoning >>> for not have been able to foresee such a situation at the time of the >>> original request. >>> >>> >> I like this, and may steal some of your language. :-) >> >> >>> Any and all requests that fall under this 'clause' category shall be >>> presented to the ARIN PPML mailing list without any identifying >>> information, other than the number of IP blocks that the requester has >>> requested within the last 12 months, the number and size of IP blocks >>> the requester has received within the last 18? months, and the [due >>> diligence] documentation presented with the 'emergency' request. >>> >>> The blocks will be provided for distribution to the requester upon >>> community consensus, following the same procedures of the PDP, but at >>> [expedited pace] timeframe. >>> >>> >> I'm not convinced that we want to inject PPML into the process in-line. >> Given that the current policy process cycle is about 6 months, I'm not >> sure if we could do an [expedited pace] that would actually be faster >> than waiting the 3 months... >> > The way I see it, the only way to present something to the entire > community is via the PPML. Unfortunately, I haven't found any method > that ARIN staff is permitted to use that would allow them to expedite > such information to the PPML, without "declaring an emergency". > > It would seem that over-using this portion of the PDP would cause the > term 'emergency' to become useless, and also, would require a policy > draft to be submitted, which is senseless regarding an IP request. > If they wanted to, the ARIN Board could set up a mechanism to do something like this. However, I'm not sure they would, for a few reasons, such as: - Balancing degree of participation with timeliness would be difficult. As you allude to, the amount of feedback on PPML can often be counted on one hand. OTOH, there are routinely 10x as many participants expressing an opinion at a public policy meeting, but those only occur twice a year. - The bottom-up policy process works well partly because it is limited to producing non-discriminatory policies that apply to the whole community. If we were to propose policy that applied to individual organizations, we would be playing a whole different ballgame with an entirely different set of requirements, legal and otherwise. So, I think we're best off using the policy process to set the overall policy and provide guidelines to ARIN staff, and then trusting them to implement the policy fairly. If necessary, they can always set up an internal procedure to escalate (appeals on) sensitive requests, all the way to the president or board level if necessary. >> However, I definitely want to see transparency in how this policy is >> being used. We do have an existing mechanism for ARIN staff to report >> back to the community on how policies are working out: at every ARIN >> meeting staff (Leslie) gives a Policy Experience Report, detailing how >> one or more aspects of policy are actually working in practice, and >> suggesting changes where necessary. And, of course, she takes questions >> as well. So I'm thinking maybe we'd want to have staff report on the >> number of waivers requested and granted, and any interesting details of >> the circumstances surrounding the requests... >> > I'm going overboard on a finer point on your proposal. Hopefully I'll be > at the next ARIN meeting to hear the Policy Experience Report. I do like > the transparency of the process. I specifically like the fact that > *anyone* can drum up ideas, throw them at the list, and see what > happens. The transparency, and bottom-up approach seems to be quite > effective (all the while spurring intriguing and very interesting dialogue). > I agree wholeheartedly. You (plural) are ARIN, and you are the ones that make the policy process work. Please keep participating. Thanks, Scott From scottleibrand at gmail.com Wed Jan 27 01:44:12 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 26 Jan 2010 22:44:12 -0800 Subject: [arin-ppml] "Each allocation/assignment size will be made, out of separate blocks reserved for that purpose." In-Reply-To: <4B5FDCD6.4000509@ibctech.ca> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> <4B5FC591.9000805@ibctech.ca> <4B5FC733.1010800@gmail.com> <4B5FDCD6.4000509@ibctech.ca> Message-ID: <4B5FE0BC.9020304@gmail.com> On 1/26/2010 10:27 PM, Steve Bertrand wrote: > I'm more concerned whether your policy will ensure that*ALL* IPv6 > addresses will fall under: "Each allocation/assignment size will be made > out of separate blocks reserved for that purpose." however... > I'm not sure I understand you here. First off, are you talking about proposal 106, or something else? Do you mean that you're worried that every size allocation being made out of a different block will cause problems? Or that somehow that won't be possible? Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at ibctech.ca Wed Jan 27 02:07:22 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Jan 2010 02:07:22 -0500 Subject: [arin-ppml] "Each allocation/assignment size will be made, out of separate blocks reserved for that purpose." In-Reply-To: <4B5FE0BC.9020304@gmail.com> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> <4B5FC591.9000805@ibctech.ca> <4B5FC733.1010800@gmail.com> <4B5FDCD6.4000509@ibctech.ca> <4B5FE0BC.9020304@gmail.com> Message-ID: <4B5FE62A.1060507@ibctech.ca> Scott Leibrand wrote: > On 1/26/2010 10:27 PM, Steve Bertrand wrote: >> I'm more concerned whether your policy will ensure that *ALL* IPv6 >> addresses will fall under: "Each allocation/assignment size will be made >> out of separate blocks reserved for that purpose." however... >> > > I'm not sure I understand you here. First off, are you talking about > proposal 106, or something else? Do you mean that you're worried that > every size allocation being made out of a different block will cause > problems? Or that somehow that won't be possible? 106. I shouldn't have mentioned that within this discussion. I figure if every allocation/assignment is documented by ARIN from a block 'reserved for X purpose', then providers who currently won't accept /48's might do so, if they know that they are within an /XX address space used exclusively for that purpose. Personally, I've accepted /48 from the get-go. However, I have routers that will fall over if someone decides to maliciously /48 up a few /32's for instance. Every ARIN block allocated or assigned should be done so from a block reserved for a particular purpose. As Owen says, we have 7/8ths more to play with after this one is done. Let ARIN pave the way for proper documentation/TE/filtering (even though ARIN doesn't have anything to do with routing policy) for the first 1/8th, and we'll all be set. Steve From steve at ibctech.ca Wed Jan 27 02:24:59 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Jan 2010 02:24:59 -0500 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B5FE046.4050701@gmail.com> References: <4B58AED5.4030705@arin.net> <4B5FB92D.9060100@gmail.com> <4B5FC591.9000805@ibctech.ca> <4B5FC733.1010800@gmail.com> <4B5FDCD6.4000509@ibctech.ca> <4B5FE046.4050701@gmail.com> Message-ID: <4B5FEA4B.90408@ibctech.ca> Scott Leibrand wrote: [ snip ] >>> I'm not convinced that we want to inject PPML into the process in-line. >>> Given that the current policy process cycle is about 6 months, I'm not >>> sure if we could do an [expedited pace] that would actually be faster >>> than waiting the 3 months... >>> >> The way I see it, the only way to present something to the entire >> community is via the PPML. Unfortunately, I haven't found any method >> that ARIN staff is permitted to use that would allow them to expedite >> such information to the PPML, without "declaring an emergency". >> >> It would seem that over-using this portion of the PDP would cause the >> term 'emergency' to become useless, and also, would require a policy >> draft to be submitted, which is senseless regarding an IP request. >> > > If they wanted to, the ARIN Board could set up a mechanism to do > something like this. However, I'm not sure they would, for a few > reasons, such as: > > - Balancing degree of participation with timeliness would be > difficult. As you allude to, the amount of feedback on PPML can often > be counted on one hand. OTOH, there are routinely 10x as many > participants expressing an opinion at a public policy meeting, but those > only occur twice a year. > - The bottom-up policy process works well partly because it is limited > to producing non-discriminatory policies that apply to the whole > community. If we were to propose policy that applied to individual > organizations, we would be playing a whole different ballgame with an > entirely different set of requirements, legal and otherwise. I can understand/appreciate that. > So, I think we're best off using the policy process to set the overall > policy and provide guidelines to ARIN staff, and then trusting them to > implement the policy fairly. If necessary, they can always set up an > internal procedure to escalate (appeals on) sensitive requests, all the > way to the president or board level if necessary. Please understand that I meant no disrespect to the staff whatsoever. The idea of 'bypassing' certain aspects were meant to bypass 'processes', not 'people' or 'levels'. I expect you (and the staff, Board, and President) know that. I did learn something though, just then. >>> However, I definitely want to see transparency in how this policy is >>> being used. We do have an existing mechanism for ARIN staff to report >>> back to the community on how policies are working out: at every ARIN >>> meeting staff (Leslie) gives a Policy Experience Report, detailing how >>> one or more aspects of policy are actually working in practice, and >>> suggesting changes where necessary. And, of course, she takes questions >>> as well. So I'm thinking maybe we'd want to have staff report on the >>> number of waivers requested and granted, and any interesting details of >>> the circumstances surrounding the requests... >>> >> I'm going overboard on a finer point on your proposal. Hopefully I'll be >> at the next ARIN meeting to hear the Policy Experience Report. I do like >> the transparency of the process. I specifically like the fact that >> *anyone* can drum up ideas, throw them at the list, and see what >> happens. The transparency, and bottom-up approach seems to be quite >> effective (all the while spurring intriguing and very interesting >> dialogue). >> > > I agree wholeheartedly. You (plural) are ARIN, and you are the ones > that make the policy process work. Please keep participating. heh. cheers! If anything, I'd like other 'lurkers' on the list to speak up, even if it's to a single person (if you don't want to post to the list directly). I've discussed with a number of other small outfits the concerns of the v4 runout and their fear of IPv6. It's the people who are reading but not posting that I'd personally like to learn from. Steve From michael.dillon at bt.com Wed Jan 27 04:31:16 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 27 Jan 2010 09:31:16 -0000 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B5FC591.9000805@ibctech.ca> Message-ID: <28E139F46D45AF49A31950F88C49745804F49570@E03MVZ2-UKDY.domain1.systemhost.net> > Any and all requests that fall under this 'clause' category > shall be presented to the ARIN PPML mailing list without any > identifying information, I would hate to see the PPML mailing list abused in this way. If people want to see statistics on various ARIN activities, they can go to the meetings or follow the reporting on the ARIN website. PPML is for discussing possible new policies. --Michael Dillon From steve at ibctech.ca Wed Jan 27 05:42:29 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Jan 2010 05:42:29 -0500 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <28E139F46D45AF49A31950F88C49745804F49570@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804F49570@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B601895.40401@ibctech.ca> michael.dillon at bt.com wrote: > >> Any and all requests that fall under this 'clause' category >> shall be presented to the ARIN PPML mailing list without any >> identifying information, > > I would hate to see the PPML mailing list abused in this way. > If people want to see statistics on various ARIN activities, > they can go to the meetings or follow the reporting on the > ARIN website. > ...well, one thing that I didn't expect was to have someone claim it as an abuse of the PPML... I've seen far worse brought up on the list, but I accept and digress ;) My off-the-wall idea was not about 'statistics'. It was regarding offering the community the ability to freely combat (or decide) on who should be appropriated remnants of IP space (in a very specific scenario, within a portion of a Draft Policy), in the only arena that I know, that would alleviate ARIN as being the 'sole discretionary' in a fair and equal manner. "without any identifying information" != statistics, imho. I don't recall mentioning any ARIN activities. Also, I'm working on getting to the Toronto meeting, and I do follow the website. > PPML is for discussing possible new policies. Absolutely, but can you not replace your "new" in that sentence with 'old', 'ineffective', 'damaging', 'conceptual'? What about 'proposed'? You always have great input... how do you think that 2.A. should be addressed? Steve From michael.dillon at bt.com Wed Jan 27 08:20:44 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 27 Jan 2010 13:20:44 -0000 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B601895.40401@ibctech.ca> Message-ID: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> > You always have great input... how do you think that 2.A. should be > addressed? The whole policy proposal is nuts. If ARIN can't give out a /14 because there is no single free block big enough, they should just send an email saying: ------ Here's some good news and some bad news. We just approved your allocation, however, we don't have any /14 or bigger sized blocks left. The biggest free block available is a /16. We could either give you that and consider the request to be completed, or we could give you 3 /16s and 2 /17s to make up the equivalent number of IP addresses out of several NON-AGGREGATABLE blocks. How do you want to proceed? -------- That doesn't need any new policy just common sense. It also doesn't need to waste everybody's time on PPML arguing over the last table scraps. --Michael Dillon From farmer at umn.edu Wed Jan 27 09:08:35 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 27 Jan 2010 08:08:35 -0600 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B6048E3.2030308@umn.edu> michael.dillon at bt.com wrote: > >> You always have great input... how do you think that 2.A. should be >> addressed? > > The whole policy proposal is nuts. > > If ARIN can't give out a /14 because there is no single free block > big enough, they should just send an email saying: > > ------ > Here's some good news and some bad news. We just approved your > allocation, however, we don't have any /14 or bigger sized > blocks left. The biggest free block available is a /16. > We could either give you that and consider the request to be > completed, or we could give you 3 /16s and 2 /17s to make > up the equivalent number of IP addresses out of several > NON-AGGREGATABLE blocks. > > How do you want to proceed? > -------- > > That doesn't need any new policy just common sense. It also doesn't > need to waste everybody's time on PPML arguing over the last table > scraps. Unfortunately arguing over table scraps is human nature, sometimes we do worse than argue. I just saw an extreme case of it on the news this morning, a group of people in Haiti were pepper sprayed to keep them from mobbing a food distribution. I apologize if that example offends anyone, but I am not certain we will not end up in an equally ugly situation at the end of IPv4, I hope not. In the heat of the situation common sense will go out the window, it always does. This and some other proposals are simply motivated by wanting to deal with this while people still have common sense about this issue. We need to give ARIN staff the tools they need to deal with things if they get ugly, or when they get ugly, if you are a pessimist. I believed the way to deal with this was to set a maximum allocation based on the amount of space ARIN had, the community didn't like that idea. This is another way to deal with the situation. I'm not completely sure about this text just yet, but I completely support the concept and intent of this proposal. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From scottleibrand at gmail.com Wed Jan 27 13:00:13 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 27 Jan 2010 10:00:13 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B607F2D.1020404@gmail.com> On 1/27/2010 5:20 AM, michael.dillon at bt.com wrote: > > >> You always have great input... how do you think that 2.A. should be >> addressed? >> > The whole policy proposal is nuts. > > If ARIN can't give out a /14 because there is no single free block > big enough, they should just send an email saying: > > ------ > Here's some good news and some bad news. We just approved your > allocation, however, we don't have any /14 or bigger sized > blocks left. The biggest free block available is a /16. > We could either give you that and consider the request to be > completed, or we could give you 3 /16s and 2 /17s to make > up the equivalent number of IP addresses out of several > NON-AGGREGATABLE blocks. > > How do you want to proceed? > -------- > What if the request is for a /14, and the biggest free blocks are all /24s? Do you want to give out 1024 non-aggregatable /24s to meet their need for a /14? Or should they be offered a single /24 from the free pool, and given the option to get their /14 via transfer? The latter is the outcome this policy would prefer, as it reduces fragmentation of the IPv4 address space, and allows available blocks to be matched with a larger number of equivalent-sized requests, rather than having them all vacuumed up by a small number of large requests. And what about when the last /24 is given out, but there are still requests coming in, and there is still small amounts of address space being reclaimed? Do you think that all requests should be denied if the pool is empty, and the first request to come in after a block is reclaimed gets it? (Pool of Bethesda style?) In that case, perhaps every requester could send in requests once a minute, all day every day, until a block becomes available. > That doesn't need any new policy just common sense. It also doesn't > need to waste everybody's time on PPML arguing over the last table > scraps. > Yes, the last few blocks will be small, but that doesn't mean someone won't want them. IMO we need to have a mechanism in place to allow for an orderly distribution of the last of the free pool, and anything that comes in afterward. This draft policy is one proposed mechanism for doing this. I'd love to hear alternative suggestions. -Scott From jcurran at arin.net Wed Jan 27 16:48:56 2010 From: jcurran at arin.net (John Curran) Date: Wed, 27 Jan 2010 16:48:56 -0500 Subject: [arin-ppml] Consumer trial activities with IPv6 Message-ID: <5E62475F-E230-4CC7-AC3A-F235819CB544@arin.net> FYI - It's particularly important for the PPML community to be aware of consumer deployments of IPv6, as consumers might not be directly represented on this list. :-) I forward this for your consideration to the extent relevant to IPv6 Internet number policy formation. /John John Curran President and CEO ARIN > From: John Jason Brzozowski > Date: Wed, 27 Jan 2010 14:23:51 -0500 > To: "nanog at nanog.org" > Conversation: Comcast IPv6 Trials > Subject: Comcast IPv6 Trials > > Folks, > > I am emailing you today to share some news that we hope you will find > interesting. > > Today we are announcing our 2010 IPv6 trial plans. For more information > please visit the following web site: > > http://www.comcast6.net > > We have also made available a partial, dual-stack version of our portal > which can be found at: > > http://ipv6.comcast.net > > Please do not hesitate to contact me via email with any questions, comments, > or clarifications. > > If you feel that others will find this information interesting feel free to > forward this message. > > Regards, > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 From gbonser at seven.com Wed Jan 27 17:32:19 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 27 Jan 2010 14:32:19 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B607F2D.1020404@gmail.com> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> > > > > What if the request is for a /14, and the biggest free blocks are all > /24s? Do you want to give out 1024 non-aggregatable /24s to meet their > need for a /14? Or should they be offered a single /24 from the free > pool, and given the option to get their /14 via transfer? The latter > is > the outcome this policy would prefer, as it reduces fragmentation of > the > IPv4 address space, and allows available blocks to be matched with a > larger number of equivalent-sized requests, rather than having them all > vacuumed up by a small number of large requests. Which brought to mind something that is related. I have not been on this list very long. Has there been discussion of some mechanism for recovery of issued but unused resources? By this I mean address blocks that are no longer in use because the company involved no longer exists or blocks that have never been put into service. A check of ipv4 PI blocks that have been issued but not advertized on the Internet for more than a year might be a place to start. I say this because I recently realized that a company I once worked for which had gone out of business still had a block of addresses and an ASN assigned to them so I contacted ARIN in order that the resources could be recovered for reuse. But I can't help but wonder how large a pool exists of allocated but unused resources. George From stephen at sprunk.org Wed Jan 27 18:06:03 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 27 Jan 2010 17:06:03 -0600 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> Message-ID: <4B60C6DB.3090108@sprunk.org> George Bonser wrote: > Which brought to mind something that is related. I have not been on > this list very long. Has there been discussion of some mechanism for > recovery of issued but unused resources? By this I mean address blocks > that are no longer in use because the company involved no longer exists > or blocks that have never been put into service. A check of ipv4 PI > blocks that have been issued but not advertized on the Internet for more > than a year might be a place to start. > > I say this because I recently realized that a company I once worked for > which had gone out of business still had a block of addresses and an ASN > assigned to them so I contacted ARIN in order that the resources could > be recovered for reuse. But I can't help but wonder how large a pool > exists of allocated but unused resources. 2007-14, now NRPM section 12, was supposed to address this. I don't think there's any new policy needed; we just need to get ARIN more active in _implementing_ the existing policy. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From scottleibrand at gmail.com Wed Jan 27 18:06:13 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 27 Jan 2010 15:06:13 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> Message-ID: <4B60C6E5.5090602@gmail.com> On 1/27/2010 2:32 PM, George Bonser wrote: > > Which brought to mind something that is related. I have not been on > this list very long. Has there been discussion of some mechanism for > recovery of issued but unused resources? By this I mean address blocks > that are no longer in use because the company involved no longer exists > or blocks that have never been put into service. A check of ipv4 PI > blocks that have been issued but not advertized on the Internet for more > than a year might be a place to start. > > I say this because I recently realized that a company I once worked for > which had gone out of business still had a block of addresses and an ASN > assigned to them so I contacted ARIN in order that the resources could > be recovered for reuse. But I can't help but wonder how large a pool > exists of allocated but unused resources. > Yes, existing policy does allow ARIN to reclaim/recover/revoke non-legacy address space for various reasons, including non-payment of fees, an organization going out of business (and not transferring the assets justifying the addresses to an acquiring organization), or a determination that the address space is no longer justified under current policies. One particular policy of interest is NRPM section 12: https://www.arin.net/policy/nrpm.html#twelve Legacy space (space allocated before the creation of ARIN, and not under RSA) is an entirely different can of worms. -Scott From tedm at ipinc.net Wed Jan 27 19:10:10 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Jan 2010 16:10:10 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> Message-ID: <4B60D5E2.9060102@ipinc.net> George Bonser wrote: >> What if the request is for a /14, and the biggest free blocks are all >> /24s? Do you want to give out 1024 non-aggregatable /24s to meet > their >> need for a /14? Or should they be offered a single /24 from the free >> pool, and given the option to get their /14 via transfer? The latter >> is >> the outcome this policy would prefer, as it reduces fragmentation of >> the >> IPv4 address space, and allows available blocks to be matched with a >> larger number of equivalent-sized requests, rather than having them > all >> vacuumed up by a small number of large requests. > > Which brought to mind something that is related. I have not been on > this list very long. Has there been discussion of some mechanism for > recovery of issued but unused resources? By this I mean address blocks > that are no longer in use because the company involved no longer exists > or blocks that have never been put into service. A check of ipv4 PI > blocks that have been issued but not advertized on the Internet for more > than a year might be a place to start. > > I say this because I recently realized that a company I once worked for > which had gone out of business still had a block of addresses and an ASN > assigned to them so I contacted ARIN in order that the resources could > be recovered for reuse. But I can't help but wonder how large a pool > exists of allocated but unused resources. > We don't know, this is why the NRPM has section 3.6.1 which is currently pending implementation - basically the ARIN staff is figuring out how to do it. They have sent many mails out already and it's my understanding that they have discovered a lot of abandoned stuff as well as a lot of stuff in use that has stale data on it - which is being corrected as they inform holders. So far there has been one presentation from ARIN staff on this effort which boiled down to (in my humble opinion) a statement that the task was way, way larger than they figured it would be. I should add as one of the 4 authors of that policy my surprise was that the ARIN staff DIDN'T think it would be a monumental task. The AC basically gave them a year to figure something out. I personally wrote an outline of how I thought they should be going about doing it (ie: go after the low hanging fruit first) but I never heard back as to the results. The discussion on the mailing list that proceeded from the policy proposal also had plenty of ideas as well on how to go about doing it. They probably are not too pleased with me though, as I initiated this back in Aug 2008 with a proposal titled "whois POC e-mail cleanup" which was later combined with 4 other later proposals and retitled - my initial proposal was sufficiently unworkable that it stimulated a second proposal 3 days later titled "annual WHOIS POC Validation" and that led to both to be combined with 2 other proposals to create the result that was eventually passed. The policy is here: https://www.arin.net/policy/proposals/2008_7.html Ted > George > > > _______________________________________________ > 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 tedm at ipinc.net Wed Jan 27 19:29:30 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Jan 2010 16:29:30 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B60C6DB.3090108@sprunk.org> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> <4B60C6DB.3090108@sprunk.org> Message-ID: <4B60DA6A.8040009@ipinc.net> Stephen Sprunk wrote: > George Bonser wrote: >> Which brought to mind something that is related. I have not been on >> this list very long. Has there been discussion of some mechanism for >> recovery of issued but unused resources? By this I mean address blocks >> that are no longer in use because the company involved no longer exists >> or blocks that have never been put into service. A check of ipv4 PI >> blocks that have been issued but not advertized on the Internet for more >> than a year might be a place to start. >> >> I say this because I recently realized that a company I once worked for >> which had gone out of business still had a block of addresses and an ASN >> assigned to them so I contacted ARIN in order that the resources could >> be recovered for reuse. But I can't help but wonder how large a pool >> exists of allocated but unused resources. > > 2007-14, now NRPM section 12, was supposed to address this. I don't > think there's any new policy needed; we just need to get ARIN more > active in _implementing_ the existing policy. > Section 12 wasn't supposed to address this. Section 12 exists mainly so that if ARIN gets a credible fraud report of an existing address holder that they can commence proceedings to revoke the allocation without having to go to a court and sue the address holder for breach of contract. Note the language: "...1.ARIN may review..." The may places this section as an OPTIONAL section, ARIN is not obligated to conduct these reviews. "...usage of any resources maintained in the..." By definition, abandoned IP resources aren't being "maintained" thus they do not fall under this section of the NRPM. This section only applies to resources that are being actively defended. Clauses like this are very common in business contracts (decent ones, anyway) The section 3.6.1, implementation of which is in-process, is the operative section that deals with the issue that George mentioned. Technically, ARIN is within compliance of the NRPM at this time, since Section 12 is optional, and Section 3.6.1 is pending implementation in the NRPM. Ted From stephen at sprunk.org Wed Jan 27 23:44:42 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 27 Jan 2010 22:44:42 -0600 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B60DA6A.8040009@ipinc.net> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> <4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> Message-ID: <4B61163A.6080408@sprunk.org> Ted Mittelstaedt wrote: > Stephen Sprunk wrote: >> 2007-14, now NRPM section 12, was supposed to address this. I don't >> think there's any new policy needed; we just need to get ARIN more >> active in _implementing_ the existing policy. > > Section 12 wasn't supposed to address this. Section 12 exists mainly > so that if ARIN gets a credible fraud report of an existing address > holder that they can commence proceedings to revoke the allocation > without having to go to a court and sue the address holder for breach > of contract. As one of the co-authors of 2007-14--and the one who wrote the majority of the text that made it into the final policy--I know _exactly_ what my intent was: to give ARIN clear authority to clean up space that was no longer justified since my previous suggestion to do so via the ACSP was rejected on the basis that ARIN had no such policy authority. Owen's intent may have been different; I'll let him speak to his if he so desires. > Note the language: > > "...1.ARIN may review..." > > The may places this section as an OPTIONAL section, ARIN is not > obligated to conduct these reviews. Of course; we neither wanted to create an undue burden on staff nor create a system where every registrant faced an annual audit of their space that would undoubtedly leave ARIN viewed in a similar light to the IRS. We hoped that giving staff discretion would allow them to develop a reasonable internal process for identifying the "low-hanging fruit" to review without bothering those that were known (or at least strongly suspected) of not holding unused resources. > "...usage of any resources maintained in the..." > > By definition, abandoned IP resources aren't being "maintained" thus > they do not fall under this section of the NRPM. This section only > applies to resources that are being actively defended. No, it applies to any resources that ARIN maintains a registration for in its database. > Technically, ARIN is within compliance of the NRPM at this time, since > Section 12 is optional, ... Yes, they are. It was our intent and desire that they'd be more active than they have been, but the policy does unfortunately allow staff to do absolutely nothing if that's what the ARIN President chooses. That was not my intent. If the activity level doesn't increase in the somewhat near future, I'll be submitting a proposal to remove the optional nature, but I hope it doesn't come to that because I think that's almost as bad as doing nothing. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From gbonser at seven.com Thu Jan 28 00:13:06 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 27 Jan 2010 21:13:06 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B61163A.6080408@sprunk.org> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com><4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> <4B61163A.6080408@sprunk.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7457@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Wednesday, January 27, 2010 8:45 PM > To: Ted Mittelstaedt; ARIN PPML > Subject: Re: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet > IPv4 Requests > > Technically, ARIN is within compliance of the NRPM at this time, > since > > Section 12 is optional, ... > > Yes, they are. It was our intent and desire that they'd be more active > than they have been, but the policy does unfortunately allow staff to > do absolutely nothing if that's what the ARIN President chooses. That > was not my intent. If the activity level doesn't increase in the > somewhat near future, I'll be submitting a proposal to remove the > optional nature, but I hope it doesn't come to that because I think > that's almost as bad as doing nothing. > > S I didn't mean to hijack/derail the conversation onto a different topic. My reason for bringing this up was my going through a thought exercise of what it might be like to go through the process that was proposed. I didn't really like the idea of using ARIN-PPML as an approval authority of requests or arbitration body for deciding what is and what is not "foreseeable" as that varies with experience. The first thing that came to mind is that it might seem a bit "cabal-ish" and ARIN-PPML would likely be accused of being a cabal the first time someone is told, in effect, "that was a dumb mistake, live with it". Another likely scenario is that the requester might say "why are you denying me resources when there are larger allocations sitting out there unused" or something to that effect. And maybe there is a large allocation to some-really-big.com that dwindled down to nothing but a single web server but some company paid a dollar-fifty for the corporate name, web domain, etc. And so now that huge allocation of IP addresses is being used by bills-fish-farm-and-pr0n.com for 42 web servers and an ftp site but the legal corporate entity of some-really-big.com still sort of exists, kinda. Once people start being denied resources, all sorts of things are going to fly out of the woodwork and resource reclamation/policing is probably going to be one of those things. George From owen at delong.com Thu Jan 28 01:38:03 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Jan 2010 22:38:03 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B60DA6A.8040009@ipinc.net> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> <4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> Message-ID: <92C6FD88-049D-45CE-9266-0F3D388D3EC1@delong.com> > > "...usage of any resources maintained in the..." > > By definition, abandoned IP resources aren't being "maintained" thus > they do not fall under this section of the NRPM. This section only > applies to resources that are being actively defended. > That line states "...maintained in the [ARIN database]..." and was intended to represent ANY resources under ARIN administrative jurisdiction whether or not abandoned. It is not intended, nor do I believe staff has interpreted it to mean abandoned resources cannot be audited or reclaimed under section 12. > Clauses like this are very common in business contracts (decent > ones, anyway) > > > The section 3.6.1, implementation of which is in-process, is the > operative section that deals with the issue that George mentioned. > > Technically, ARIN is within compliance of the NRPM at this time, since > Section 12 is optional, and Section 3.6.1 is pending implementation in > the NRPM. > Both are tools. Section 3.6.1 provides for detection and identification of abandoned resources. Section 12 provides for the reclamation of underutilized resources regardless of the method used to identify or detect them. Owen (This is just my own opinion, not an official statement from ARIN or the AC). -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu Jan 28 03:30:51 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 28 Jan 2010 08:30:51 -0000 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B607F2D.1020404@gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804F49EB5@E03MVZ2-UKDY.domain1.systemhost.net> > What if the request is for a /14, and the biggest free blocks > are all /24s? Do you want to give out 1024 non-aggregatable > /24s to meet their need for a /14? If the applicant has justified a /14's worth of space, and ARIN asks the applicant about 1024 /24s and the applicant says that they can indeed make use of them, then basically, yes. When the shelves are bare, you either accept crumbs, or go to the new IPv6 supermarket. > Or should they be offered > a single /24 from the free pool, and given the option to get > their /14 via transfer? Definitely not. The option to get a /14 via transfer is something that needs to be raised before an applicant submits their application. ARIN needs to be clear about what blocks of what sizes, are on the shelf waiting. > The latter is the outcome this > policy would prefer, as it reduces fragmentation of the > IPv4 address space, and allows available blocks to be matched > with a larger number of equivalent-sized requests, rather > than having them all vacuumed up by a small number of large requests. If that was the goal then a simple change to policy that states ARIN will only issue a single block which is the largest aggregate that fits within the applicant's approved size. That works today, and right up to the end. > And what about when the last /24 is given out, but there are > still requests coming in, and there is still small amounts of > address space being reclaimed? Do you think that all > requests should be denied if the pool is empty, and the first > request to come in after a block is reclaimed gets it? Yes. ARIN is not an auction house or a second hand shop. The transfer policy exists so that people can find those reclaimable blocks without bogging down ARIN with the details. > In that case, perhaps every requester > could send in requests once a minute, all day every day, > until a block becomes available. Then ARIN can censure the requester and block their IP addresses from ARIN services. Meantime their competitors will be advertising to buy reclaimable blocks and win the day. --Michael Dillon From owen at delong.com Thu Jan 28 04:02:40 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Jan 2010 01:02:40 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <28E139F46D45AF49A31950F88C49745804F49EB5@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804F49EB5@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <60C4B6D1-8B5F-4AA9-8E5A-A625E8FC33DF@delong.com> On Jan 28, 2010, at 12:30 AM, wrote: > >> What if the request is for a /14, and the biggest free blocks >> are all /24s? Do you want to give out 1024 non-aggregatable >> /24s to meet their need for a /14? > > If the applicant has justified a /14's worth of space, and ARIN > asks the applicant about 1024 /24s and the applicant says that > they can indeed make use of them, then basically, yes. > > When the shelves are bare, you either accept crumbs, or go to > the new IPv6 supermarket. > The question here isn't about whether or not the requestor should accept crumbs, it's about whether the community is better served by giving all the remaining crumbs to a small number of large requestors, or, by giving some of the crumbs to a larger number of (potentially smaller) requestors. >> Or should they be offered >> a single /24 from the free pool, and given the option to get >> their /14 via transfer? > > Definitely not. The option to get a /14 via transfer is > something that needs to be raised before an applicant submits > their application. ARIN needs to be clear about what blocks of > what sizes, are on the shelf waiting. > What's waiting on which shelf? ARIN will not have 100% visibility into the transfer availability. The ARIN shelf, OTOH, may well have rapidly varying contents such that a /14 was available when the person inquired, but, no longer available by the time ARIN received the application. >> The latter is the outcome this >> policy would prefer, as it reduces fragmentation of the >> IPv4 address space, and allows available blocks to be matched >> with a larger number of equivalent-sized requests, rather >> than having them all vacuumed up by a small number of large requests. > > If that was the goal then a simple change to policy that > states ARIN will only issue a single block which is the > largest aggregate that fits within the applicant's approved > size. That works today, and right up to the end. > What if the requestor thinks ARIN is likely to reclaim a large enough block and wants to wait for it? This policy allows the requestor to choose to sit in the queue in case such a block becomes available. >> And what about when the last /24 is given out, but there are >> still requests coming in, and there is still small amounts of >> address space being reclaimed? Do you think that all >> requests should be denied if the pool is empty, and the first >> request to come in after a block is reclaimed gets it? > > Yes. ARIN is not an auction house or a second hand shop. The > transfer policy exists so that people can find those reclaimable > blocks without bogging down ARIN with the details. > But some address space gets returned to or reclaimed by ARIN through various processes. Should we really turn the address distribution into a lottery based on timing your request to match the arrival of resources? That seems far worse to me. >> In that case, perhaps every requester >> could send in requests once a minute, all day every day, >> until a block becomes available. > > Then ARIN can censure the requester and block their IP > addresses from ARIN services. Meantime their competitors > will be advertising to buy reclaimable blocks and win > the day. > Yeah, I think that the address application timing lottery that you are proposing is extremely poor stewardship, regardless of what set of rules you propose for preventing people from making frequent enough entries to attempt to guarantee a win. Owen From michael.dillon at bt.com Thu Jan 28 10:18:53 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 28 Jan 2010 15:18:53 -0000 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <60C4B6D1-8B5F-4AA9-8E5A-A625E8FC33DF@delong.com> Message-ID: <28E139F46D45AF49A31950F88C49745804FAA19B@E03MVZ2-UKDY.domain1.systemhost.net> > The question here isn't about whether or not the requestor > should accept crumbs, it's about whether the community is > better served by giving all the remaining crumbs to a small > number of large requestors, or, by giving some of the crumbs > to a larger number of (potentially smaller) requestors. In the real world, talking about real crumbs, or at least food, they give all the crumbs to a few strong members of the community so that those members can apply their energy to getting more food to save others from starvation. Of course not all communities are so clever, and some of them ration out the crumbs, praying for a miracle and then they all die together. I suggest that it is not ARIN's business to decide what better serves the community, since ARIN is not lord and master of the community, but its servant. ARIN should only try to be reasonably fair, not make heroic efforts whose outcome could be worse, and whose outcome is certainly unknowable. > > Definitely not. The option to get a /14 via transfer is > something that > > needs to be raised before an applicant submits their > application. ARIN > > needs to be clear about what blocks of what sizes, are on the shelf > > waiting. > > > What's waiting on which shelf? ARIN will not have 100% > visibility into the transfer availability. So what? ARINs job is to manage its own shelf, not commandeer everyone else's. > The ARIN shelf, > OTOH, may well have rapidly varying contents such that a /14 > was available when the person inquired, but, no longer > available by the time ARIN received the application. That's life. When the cupboard is bare, it is bare. Finito la commedia. It would be wrong of ARIN to publish the available IP address blocks as any kind of a guarantee, but it is right to publish availability information as a snapshot of what WAS AVAILABLE at the time the report was produced, which may be a few hours out of date. No need to publish more than daily data. > What if the requestor thinks ARIN is likely to reclaim a > large enough block and wants to wait for it? This policy > allows the requestor to choose to sit in the queue in case > such a block becomes available. What if pigs might learn to fly by growing silk ears. Requestors might want to sit in the silk purse queue and wait for a flying sow to appear over the horizon. Far better for them to get down to the rag market and haggle over the price of an old silk dress that could be reworked into a silk purse. In other words, if you look at the ARIN available blocks and it seems that there is a significant risk that you will not get what you need, then don't waste any more time with ARIN, and hunt out in the wild for potential transfer blocks. > But some address space gets returned to or reclaimed by ARIN > through various processes. Should we really turn the address > distribution into a lottery based on timing your request to > match the arrival of resources? That seems far worse to me. By that stage IPv4 address allocation is already a crap shoot regardless of what ARIN does. It's like aid distribution in disaster areas. The aid organizations try to do it in an orderly way by giving tokens to mothers or every 10th person or whatever. But once that person with the goods is out of view, who knows what happens. In one case they were hoping to seed a market by giving it to every 10th person, but they started a riot instead. The lesson is that you cannot orchestrate human behavior to the nth degree, not in Haiti and not in the IPv4 address allocation arena. Back off and let nature take its course, which in the case of ARIN is deployment of IPv6 everywhere. We need more humility instead of thinking that we can engineer solutions to every problem. Many problems are beyond engineering, otherwise we would already be living in a technocracy, not a democracy. > > Then ARIN can censure the requester and block their IP > addresses from > > ARIN services. Meantime their competitors will be > advertising to buy > > reclaimable blocks and win the day. > > > Yeah, I think that the address application timing lottery > that you are proposing is extremely poor stewardship, > regardless of what set of rules you propose for preventing > people from making frequent enough entries to attempt to > guarantee a win. DoS attackers deserve what they get. I gather you would rather see a system where people apply to ARIN once, demonstrate their need once, and get their choice of whatever addresses are on the shelf, or a chit to be used when they find addresses in the market, or a place in a waiting list for reclaimed addresses on the shelf, or some combination of the three. Let's see, little ISP needs a /22 and applies to ARIN. They are approved but there is only one /24 on the shelf. Little ISP says, we'll take it, plus a chit for another /24, plus a place in the queue for two more /24s. If they are unhappy with the results of their market search, ARIN lets them exchange the chit for another place in the queue, behind their original queue postion for two /24s. That could work. How could it be done with a simple policy that doesn't overmanage the situation? --Michael Dillon From scottleibrand at gmail.com Thu Jan 28 11:52:37 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 Jan 2010 08:52:37 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <28E139F46D45AF49A31950F88C49745804FAA19B@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804FAA19B@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B61C0D5.4070900@gmail.com> On 1/28/2010 7:18 AM, michael.dillon at bt.com wrote: > > I gather you would rather see a system where people apply to > ARIN once, demonstrate their need once, and get their choice > of whatever addresses are on the shelf, > or a chit to be used when they find addresses in the market, > or a place in a waiting list for reclaimed addresses on the shelf, > or some combination of the three. > > Let's see, little ISP needs a /22 and applies to ARIN. They are > approved but there is only one /24 on the shelf. Little ISP > says, we'll take it, plus a chit for another /24, plus a place > in the queue for two more /24s. If they are unhappy with the > results of their market search, ARIN lets them exchange the > chit for another place in the queue, behind their original > queue postion for two /24s. > That's similar to what I'm proposing, but 2010-1's process is actually slightly simpler: the ISP can either take the /24, and go away for 3 months, or they can get in line for a /22 or a /23. They can't be in multiple places in multiple lines, so "place in the queue" and "chit" reduce to the exact same thing. > That could work. How could it be done with a simple policy that > doesn't overmanage the situation? > Please feel free to write it up, so we can do a direct apples-to-apples comparison. Or, if you prefer, feel free to point out which parts of 2010-1 are overly complicated and should be simplified or eliminated. Thanks! Scott From farmer at umn.edu Thu Jan 28 13:05:21 2010 From: farmer at umn.edu (David Farmer) Date: Thu, 28 Jan 2010 12:05:21 -0600 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria - revised In-Reply-To: <8AEF20A7-9CA8-48E4-AF6F-6373E91C6DB9@akamai.com> References: <4B3B8322.1030609@arin.net> <443de7ad0912300935s1920b450od576b4813582609@mail.gmail.com> <8AEF20A7-9CA8-48E4-AF6F-6373E91C6DB9@akamai.com> Message-ID: <4B61D1E1.1070308@umn.edu> Martin Hannigan wrote: > > I'm not really in support of this policy as it stands, but > might be with edits that clean it up. I don't agree with nibbles. Why > not get it out of the way now and finally get it off of the to-do list? I've been working with Chris the original author of this and Cathy the AC Shepherd for this proposal and have come up with the following as a complete rewrite of the IPv6 Allocation section. So what do you all think. I hope the AC will put this forward as a Draft policy for adoption discussion in Toronto. If you have suggestion you think should go into this before it goes for staff and legal assessment please let me know ASAP. Thanks ---- Policy statement: Delete section 6.4.3. Minimum Allocation. Modify the following sections; 6.5.1 Initial allocations for ISPs and LIRs 6.5.1.1. Initial allocation size Organizations that meet at least one of the following criteria are eligible to receive a minimum allocation of /32. Requests for larger allocations, reasonably justified with supporting documentation, will be evaluated based on the number of existing users and the extent of the organization's infrastructure. 6.5.1.2. Criteria for initial allocation to ISPs Organizations may justify an initial allocation for the purpose of assigning addresses to other organizations or customers that it will provide IPv6 Internet connectivity to, with an intent to provide global reachability for the allocation within 12 months, by meeting one of the following additional criteria: a. Having a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By providing a reasonable plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. 6.5.1.3. Criteria for initial allocation to other LIRs Organizations may justify an initial allocation for the purpose of assigning addresses to other organizations or customers that it will provide IPv6 based network connectivity services to, not necessarily Internet connected, by meeting one of the following additional criteria: a. Having a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or; b. By providing a reasonable technical justification, indicating why an allocation is necessary, including the intended purposes for the allocation, and describing the network infrastructure the allocation will be used to support. Justification must include a plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Rationale: This proposal provides a complete rework of the IPv6 allocation criteria while maintaining many of the basic concepts contained in the current policies. The order of the subsections of 6.5.1 are rearranged moving the initial allocation size to 6.5.1.1. This will facilitate adding future criteria without additional renumbering the current policies. The initial allocation criteria include the following general concepts; ? The need for an allocation is only justified by the need to assign resource to customers. ? When the need to provide Internet connectivity is use to justify resources it is implied the resources should be advertised to the Internet, within some reasonable time frame after they are received. ? IPv4 resources may be use to justify the need for IPv6 resources. ? An ISP may justify independent resource by being Multihomed or planning to assign IPv6 resource to some minimum number of customers. ? It should be possible to justify an IPv6 allocation for more than just classical ISPs, such as non-connected networks or other types of LIRs. But additional justification should be required, describing the purpose and network infrastructure the allocation will be supporting. Finally, section 6.4.3 Minimum Allocation, is deleted as it is incomplete and redundant anyway. Timetable for implementation: Immediate -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From tedm at ipinc.net Thu Jan 28 15:00:06 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 12:00:06 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B61163A.6080408@sprunk.org> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> <4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> <4B61163A.6080408@sprunk.org> Message-ID: <4B61ECC6.7090007@ipinc.net> Stephen Sprunk wrote: > Ted Mittelstaedt wrote: >> Stephen Sprunk wrote: >>> 2007-14, now NRPM section 12, was supposed to address this. I don't >>> think there's any new policy needed; we just need to get ARIN more >>> active in _implementing_ the existing policy. >> Section 12 wasn't supposed to address this. Section 12 exists mainly >> so that if ARIN gets a credible fraud report of an existing address >> holder that they can commence proceedings to revoke the allocation >> without having to go to a court and sue the address holder for breach >> of contract. > > As one of the co-authors of 2007-14--and the one who wrote the majority > of the text that made it into the final policy--I know _exactly_ what my > intent was: to give ARIN clear authority to clean up space that was no > longer justified since my previous suggestion to do so via the ACSP was > rejected on the basis that ARIN had no such policy authority. > I think section 12 makes that part (giving them the authority) pretty clear. > Owen's intent may have been different; I'll let him speak to his if he > so desires. > >> Note the language: >> >> "...1.ARIN may review..." >> >> The may places this section as an OPTIONAL section, ARIN is not >> obligated to conduct these reviews. > > Of course; we neither wanted to create an undue burden on staff nor > create a system where every registrant faced an annual audit of their > space that would undoubtedly leave ARIN viewed in a similar light to the > IRS. > > We hoped that giving staff discretion would allow them to develop a > reasonable internal process for identifying the "low-hanging fruit" to > review without bothering those that were known (or at least strongly > suspected) of not holding unused resources. > >> "...usage of any resources maintained in the..." >> >> By definition, abandoned IP resources aren't being "maintained" thus >> they do not fall under this section of the NRPM. This section only >> applies to resources that are being actively defended. > > No, it applies to any resources that ARIN maintains a registration for > in its database. > >> Technically, ARIN is within compliance of the NRPM at this time, since >> Section 12 is optional, ... > > Yes, they are. It was our intent and desire that they'd be more active > than they have been, but the policy does unfortunately allow staff to do > absolutely nothing if that's what the ARIN President chooses. The policy which you wrote. Since staff can only divine your intent by what you wrote, when you make it optional, they naturally are going to decide that your intent was for it to NOT be a mandate. This is kind of like the parents who tell the children "Honey you really shouldn't eat that cookie" then slap the kid when he eats the cookie. The parents think they are giving a command by using politically correct language that wraps a directive in a suggestion, the kid naturally takes it literally and then gets slapped - when in reality the parent shouldn't have been ambiguous. This is why whoever started the politically correct movement needs to be shot on sight. It has done far more damage in getting people into the habit of using mealy-mouthed words when they should be saying what they mean. > That was > not my intent. If the activity level doesn't increase in the somewhat > near future, I would not expect that it should. In fact, I would actively oppose any "veiled threat" that ARIN staff is misinterpreting Section 12. I think that by ignoring section 12 except when they need it, ARIN staff is doing EXACTLY what they should be doing - following the NRPM as it is written. It's your fault that you made it optional when you intended that it be mandatory, don't blame ARIN staff for your screwup. > I'll be submitting a proposal to remove the optional > nature, Please do so. I would support it. > but I hope it doesn't come to that because I think that's almost > as bad as doing nothing. > I want the staff to follow the NRPM. If the NRPM makes something optional, it should be optional. I do not want some politically correct NRPM where you have to substitute "must" every time you see the word "should" just because a bunch of garlic-eaters are afraid that someone who reads it might get upset about being told what to do. Ted From tedm at ipinc.net Thu Jan 28 15:06:00 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 12:06:00 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7457@RWC-EX1.corp.seven.com> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com><4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> <4B61163A.6080408@sprunk.org> <5A6D953473350C4B9995546AFE9939EE081F7457@RWC-EX1.corp.seven.com> Message-ID: <4B61EE28.9030604@ipinc.net> George Bonser wrote: > > Once people start being denied resources, all sorts of things are > going to fly out of the woodwork and resource reclamation/policing is > probably going to be one of those things. > That's right. Which is why it is CRITICAL that resource/reclamation policy be put into the NRPM NOW, so that we are not arguing over it in an atmosphere where ARIN is under pressure from people wanting IPv4 resources and the discussion gets so emotional that we have orgs feeling as though their only option is to ignore ARIN completely. We aren't stupid people and we have the brains needed to imagine the likely scenarios post-IPv4 runout and write policy in advance of those scenarios to alleviate problems. If we cannot do this we frankly don't have any business writing policy for ARIN at all, and the entire policy proposal process ought to be scrapped. Ted From tedm at ipinc.net Thu Jan 28 15:14:06 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 12:14:06 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <92C6FD88-049D-45CE-9266-0F3D388D3EC1@delong.com> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> <4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> <92C6FD88-049D-45CE-9266-0F3D388D3EC1@delong.com> Message-ID: <4B61F00E.5060402@ipinc.net> Owen DeLong wrote: >> "...usage of any resources maintained in the..." >> >> By definition, abandoned IP resources aren't being "maintained" thus >> they do not fall under this section of the NRPM. This section only >> applies to resources that are being actively defended. >> > That line states "...maintained in the [ARIN database]..." and was intended > to represent ANY resources under ARIN administrative jurisdiction whether > or not abandoned. It is not intended, nor do I believe staff has interpreted > it to mean abandoned resources cannot be audited or reclaimed under > section 12. > >> Clauses like this are very common in business contracts (decent >> ones, anyway) >> >> >> The section 3.6.1, implementation of which is in-process, is the >> operative section that deals with the issue that George mentioned. >> >> Technically, ARIN is within compliance of the NRPM at this time, since >> Section 12 is optional, and Section 3.6.1 is pending implementation in >> the NRPM. >> > Both are tools. Section 3.6.1 provides for detection and identification > of abandoned resources. Section 12 provides for the reclamation of > underutilized resources regardless of the method used to identify or > detect them. > Correct - keep in mind though that while abandoned resources are underutilized resources, underutilized resources are not abandoned resources. By definition an abandoned resource does not have an organization that is defending a claim on it, and it is a waste of time to attempt to "reclaim" it through any review/reclamation procedures that Section 12 may outline. I mean, for goodness sake, if no POC on a resource is valid, how is ARIN supposed to "solicited information from the resource holder" (that's right out of section 12) when there's no valid contact for a resource holder? Ted > Owen > (This is just my own opinion, not an official statement from ARIN or > the AC). > > > From stephen at sprunk.org Thu Jan 28 15:26:46 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Jan 2010 14:26:46 -0600 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B61F00E.5060402@ipinc.net> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> <4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> <92C6FD88-049D-45CE-9266-0F3D388D3EC1@delong.com> <4B61F00E.5060402@ipinc.net> Message-ID: <4B61F306.5090805@sprunk.org> Ted Mittelstaedt wrote: > Owen DeLong wrote: >> Both are tools. Section 3.6.1 provides for detection and >> identification of abandoned resources. Section 12 provides for the >> reclamation of underutilized resources regardless of the method used >> to identify or detect them. > > Correct - keep in mind though that while abandoned resources are > underutilized resources, underutilized resources are not abandoned > resources. Nit: underutilized resources are not _necessarily_ abandoned, i.e. "abandoned" is a subset of "underutilized". > By definition an abandoned resource does not have an organization that > is defending a claim on it, and it is a waste of time to attempt to > "reclaim" it through any review/reclamation procedures that Section 12 > may outline. > > I mean, for goodness sake, if no POC on a resource is valid, how is > ARIN supposed to "solicited information from the resource holder" > (that's right out of section 12) when there's no valid contact for a > resource holder? If the POCs are not valid, then ARIN should make a reasonable effort to contact them (or the organization itself) via some other means. If ARIN is unsuccessful, then the registrant has obviously not provided the necessary information to fulfill their requirements under the policy and the resource can be revoked. IIRC, failing to keep your contact information current (or pay fees) is a violation of the RSA, so ARIN could reclaim "abandoned" resources covered by an RSA without this policy. ARIN's authority to reclaim legacy (non-RSA, non-LRSA) resources in general is an unresolved question, though, and one that 2007-14 deliberately sidestepped to prevent the debate from getting hijacked. You are welcome to submit a policy proposal to change any of the above, of course. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From aaron at wholesaleinternet.net Thu Jan 28 15:01:44 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 28 Jan 2010 14:01:44 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality Message-ID: <02c701caa054$b71df010$2559d030$@net> I do not feel the AC should abandon Policy Proposal 95: Customer Confidentiality. I formally petition to move the following text forward for discussion on the list and at the next Public Policy Meeting. I would appreciate it if anyone this policy applies to would support moving this proposal forward by posting statements in support of the petition to this list. 1. Policy Proposal Name: Customer Confidentiality 2. Proposal Originator: Aaron Wendel 3. Proposal Version: 2.0 4. Date: 10 June 2009 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: ISPs may choose to enter the customer's name along with the ISP's address and phone number in reassignments and reallocations in lieu of the customer's address and phone number. The customer's actual information must be provided to ARIN on request and will be held in the strictest confidence. 8. Rationale: Version 2.0 clarifies the need for the customer name to remain in the SWIP and RWHOIS information. Customer contact lists are one of the most proprietary and confidential pieces of information in any business. The requirements for ISPs to publish those lists via SWIP or RWHOIS runs contrary to good business practices and invites competitors and others to solicit both individuals and companies receiving reassignments and sub allocations from upstream providers. 9. Timetable for implementation: immediate Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 Kansas City, MO 64106 816-256-3031 From tedm at ipinc.net Thu Jan 28 16:16:36 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 13:16:36 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B61F306.5090805@sprunk.org> References: <28E139F46D45AF49A31950F88C49745804F4997B@E03MVZ2-UKDY.domain1.systemhost.net> <4B607F2D.1020404@gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7437@RWC-EX1.corp.seven.com> <4B60C6DB.3090108@sprunk.org> <4B60DA6A.8040009@ipinc.net> <92C6FD88-049D-45CE-9266-0F3D388D3EC1@delong.com> <4B61F00E.5060402@ipinc.net> <4B61F306.5090805@sprunk.org> Message-ID: <4B61FEB4.6070803@ipinc.net> Stephen Sprunk wrote: > Ted Mittelstaedt wrote: >> Owen DeLong wrote: >>> Both are tools. Section 3.6.1 provides for detection and >>> identification of abandoned resources. Section 12 provides for the >>> reclamation of underutilized resources regardless of the method used >>> to identify or detect them. >> Correct - keep in mind though that while abandoned resources are >> underutilized resources, underutilized resources are not abandoned >> resources. > > Nit: underutilized resources are not _necessarily_ abandoned, i.e. > "abandoned" is a subset of "underutilized". > Right, exactly. >> By definition an abandoned resource does not have an organization that >> is defending a claim on it, and it is a waste of time to attempt to >> "reclaim" it through any review/reclamation procedures that Section 12 >> may outline. >> >> I mean, for goodness sake, if no POC on a resource is valid, how is >> ARIN supposed to "solicited information from the resource holder" >> (that's right out of section 12) when there's no valid contact for a >> resource holder? > > If the POCs are not valid, then ARIN should make a reasonable effort to > contact them (or the organization itself) via some other means. Correct. In one of the early drafts of 3.6.1 we had defined a procedure where staff would do this - an objection was made that this unnecessarily tied staffs hands (?!) so we removed that in order to get the proposal passed. > If ARIN > is unsuccessful, then the registrant has obviously not provided the > necessary information to fulfill their requirements under the policy and > the resource can be revoked. > > IIRC, failing to keep your contact information current (or pay fees) is > a violation of the RSA, so ARIN could reclaim "abandoned" resources > covered by an RSA without this policy. Absolutely, While I'm quite sure ARIN will do anything possible to avoid filing a lawsuit, or provoking a lawsuit against them, in my opinion also, ARIN is on very firm legal footing here. The RSA requires contact information to be supplied, and if the contact info is bogus it certainly doesn't qualify as contact info. > ARIN's authority to reclaim > legacy (non-RSA, non-LRSA) resources in general is an unresolved > question, though, and one that 2007-14 deliberately sidestepped to > prevent the debate from getting hijacked. > > You are welcome to submit a policy proposal to change any of the above, > of course. > I'm waiting for 3.6.1 to become part of the NRPM. I had actually not expected ARIN and the AC to agree to allow it to be in limbo for a year, in "implementation" state. I want to see what ARIN staff comes up with because whether or not they are foot-dragging, the AC will eventually put this in the NRPM and staff will have no choice but to implement it. And that will likely generate some refinements. My gut feeling Stephen is that there are far more abandoned IPv4 resouces out there than IPv4 resources held by orgs which are fraudulently holding them and not using them. I am assuming that by merely cleaning up whois, that ARIN will self-generate enough IPv4 to keep them busy handing out small allocations for many more years before it's necessary to go after the fraudulently held resources. Ted From tedm at ipinc.net Thu Jan 28 16:29:26 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 13:29:26 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B58AED5.4030705@arin.net> References: <4B58AED5.4030705@arin.net> Message-ID: <4B6201B6.20604@ipinc.net> My only comment to the AC on this is I think that you need to give ARIN the ability to pull a request off the waiting list if they can no longer reach the requester. If a request on the list languishes for years, it may only be satisfied once the Internet has shifted from IPv4 to IPv6 and orgs are abandoning IPv4 is droves - and at that time if they cannot reach the requester, it seems that the request will then be in limbo. Ted Member Services wrote: > Draft Policy 2010-1 > Waiting List for Unmet IPv4 Requests > > On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting List > for Unmet IPv4 Requests" as a draft policy for adoption discussion on > the PPML and at the Public Policy Meeting in Toronto in April. > > The draft was developed by the AC from Policy Proposal "97. Waiting List > for Unmet IPv4 Requests". Per the Policy Development Process the AC > submitted text to ARIN for a staff and legal assessment prior to its > selection as a draft policy. Below the draft policy is the ARIN staff > and legal assessment, including the original proposal text. > > Draft Policy 2010-1 is below and can be found at: > https://www.arin.net/policy/proposals/2010_1.html > > You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to > the April Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2010-1 > Waiting List for Unmet IPv4 Requests > > Version/Date: 21 January 2010 > > Policy statement: > Replace 4.1.6 with: > > 4.1.6. Aggregation > > In order to preserve aggregation, ARIN attempts to issue blocks of > addresses on appropriate "CIDR-supported" bit boundaries. As long as > sufficient space is available, ARIN may reserve space to maximize > aggregation possibilities. ARIN will make each allocation and assignment > as a single continuous range of addresses. > > Add new section 4.1.8: > > 4.1.8 Unmet requests > > In the event that ARIN does not have a contiguous block of addresses of > sufficient size to fulfill a qualified request, ARIN will provide the > requesting organization with the option to either modify their request > and request a smaller size block, or be placed on a waiting list of > pre-qualified recipients. Repeated requests, in a manner that would > circumvent 4.1.6, are not allowed: an organization may only receive one > allocation, assignment, or transfer every 3 months, but ARIN, at its > sole discretion, may waive this requirement if the requester can > document an unforeseen change in circumstances since their last request. > Qualified requesters whose request cannot be immediately met will also > be advised of the availability of the transfer mechanism in section 8.3 > as an alternative mechanism to obtain IPv4 addresses. > > 4.1.8.1 Waiting list > > The position of each qualified request on the waiting list will be > determined by the date it was approved. Each organization may have one > approved request on the waiting list at a time. > > 4.1.8.2 Fulfilling unmet needs > > As address blocks become available for allocation, ARIN will fulfill > requests on a first-approved basis, subject to the size of each > available address block and a re-validation of the original request. > Requests will not be partially filled. Any requests met through a > transfer will be considered fulfilled and removed from the waiting list. > > 8. Rationale: > > ARIN will soon be unable to meet all approved requests for IPv4 address > space. In the absence of a policy like this, it is unclear what ARIN > should do with subsequent requests. > > This policy would allocate reclaimed address blocks (and the last of the > ARIN free pool) on a first-come-first-served basis, while preserving > aggregation to the degree possible. As the free pool shrinks, requests > larger than the largest block left would be placed on a waiting list, > while smaller requests would use up the rest of it, until all requests > have to go on the waiting list. As additional reclaimed addresses become > available, the requests that have been waiting the longest would be met > first. If a requester gets the addresses they need via transfer, then > they would be removed from the waiting list and would need to wait and > submit a new request for additional address space, either directly or > via transfer. > > FAQ: > > Q1: The effect of 2009-8, if implemented by the Board, is to allow > transfers to be up to a 12 month supply of resources and up to a 3 month > supply for resource from the ARIN free pool. Does that jive with your > intent for this policy? > > A1: Correct. After we get to the last /8, you can request up to a > 3-month supply from the free pool, but only every 3 months unless you > can document an unforeseen change in circumstances since your last > request. However, if you get the space via transfer, you can get a block > big enough for 12 month's need, and if you end up using it up faster, > you can submit another request after 3 months. > > Q2: If I were on the waiting list, and subsequently received a transfer > via 8.3, would I be removed from the waiting list? > > A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer > will be considered fulfilled and removed from the waiting list." > > Q3: Would receipt of an M&A transfer remove you from the waiting list, too? > > A3: I think that depends on how the M&A is justified. If you acquire a > company that is already efficiently utilizing all its IP space, I don't > think that would count toward fulfilling an outstanding need that you > have a request on the waiting list for. However, if your justification > for keeping the space held by the acquired company is that you plan to > use it for new stuff, then that would meet an outstanding need, and a > request for that same need would be considered fulfilled and removed > from the waiting list. > > Q4: What about Multiple Discrete Networks? > > A4: Allocations and assignments to organizations using the Multiple > Discrete Networks policy must still be made as a single continuous range > of addresses. This preserves future aggregatability of the space, and > ensures fairness between MDN and ordinary requests. > > Timetable for implementation: Immediate. > > > ##### > > > STAFF ASSESSMENT > > Proposal: Waiting List for Unmet IPv4 Requests > Proposal Version: Updated by AC and given to staff for assessment on 29 > Dec 2009 > > Date of Assessment: 12 January 2010 > > 1. Proposal Summary (Staff Understanding) > > Staff understands that this proposal would create a waiting list for > requestors whose IPv4 address needs cannot be fulfilled by ARIN at the > time of the request approval. The proposal includes text to prevent > requestors from gaming the policy's intent by forbidding requestors from > making multiple requests of a small size and limiting the issuance of > space to no more than once every 3 months. > > 2. Comments > > A. ARIN Staff Comments > > ? In section 4.1.8, the author says ?Repeated requests, in a manner that > would circumvent 4.1.6, are not allowed: an organization may only > receive one allocation, assignment, or transfer every 3 months, but > ARIN, at its sole discretion, may waive this requirement if the > requester can document an unforeseen change in circumstances since their > last request?. > > As written, the portion of the policy that starts with ?but ARIN, at its > sole discretion? gives no concrete criteria for staff to use in its > assessment of the request. This ?exception clause? is open to > interpretation and may not be applied consistently by staff if there are > no guidelines or rules for staff to follow. It essentially allows ARIN > staff to determine the policy criteria for who can or can?t qualify > under this waiver. > > B. ARIN General Counsel > > "At this time counsel has no significant legal comments. Any system to > order and prioritize requests for resources which may exceed the > available resources must permit consistent administration by ARIN." > > 3. Resource Impact > > This policy would have moderate resource impact. It is estimated that > implementation would occur within 6 months after ratification by the > ARIN Board of Trustees. The following would be needed in order to > implement: > > ? The development of software to monitor IPv4 returns, a ?waiting list? > that will include request size as well as minimum size acceptable, and a > system that will match/compare returns with the waiting list > ? Modifications to the management web application > ? Changes to current business processes > ? Updated guidelines > ? Staff training > > > > 4. Proposal Text: Waiting list for unmet IPv4 requests > > Replace 4.1.6 with: > 4.1.6. Aggregation > In order to preserve aggregation, ARIN attempts to issue blocks of > addresses on appropriate "CIDR-supported" bit boundaries. As long as > sufficient space is available, ARIN may reserve space to maximize > aggregation possibilities. ARIN will make each allocation and assignment > as a single continuous range of addresses. > Add new section 4.1.8: > > 4.1.8 Unmet requests > In the event that ARIN does not have a contiguous block of addresses of > sufficient size to fulfill a qualified request, ARIN will provide the > requesting organization with the option to either modify their request > and request a smaller size block, or be placed on a waiting list of > pre-qualified recipients. Repeated requests, in a manner that would > circumvent 4.1.6, are not allowed: an organization may only receive one > allocation, assignment, or transfer every 3 months, but ARIN, at its > sole discretion, may waive this requirement if the requester can > document an unforeseen change in circumstances since their last request. > Qualified requesters whose request cannot be immediately met will also > be advised of the availability of the transfer mechanism in section 8.3 > as an alternative mechanism to obtain IPv4 addresses. > > 4.1.8.1 Waiting list > The position of each qualified request on the waiting list will be > determined by the date it was approved. Each organization may have one > approved request on the waiting list at a time. > > 4.1.8.2 Fulfilling unmet needs > As address blocks become available for allocation, ARIN will fulfill > requests on a first-approved basis, subject to the size of each > available address block and a re-validation of the original request. > Requests will not be partially filled. Any requests met through a > transfer will be considered fulfilled and removed from the waiting list. > > > Rationale: > ARIN will soon be unable to meet all approved requests for IPv4 address > space. In the absence of a policy like this, it is unclear what ARIN > should do with subsequent requests. > This policy would allocate reclaimed address blocks (and the last of the > ARIN free pool) on a first-come-first-served basis, while preserving > aggregation to the degree possible. As the free pool shrinks, requests > larger than the largest block left would be placed on a waiting list, > while smaller requests would use up the rest of it, until all requests > have to go on the waiting list. As additional reclaimed addresses become > available, the requests that have been waiting the longest would be met > first. If a requester gets the addresses they need via transfer, then > they would be removed from the waiting list and would need to wait and > submit a new request for additional address space, either directly or > via transfer. > > > > > FAQ: > Q1: The effect of 2009-8, if implemented by the Board, is to allow > transfers to be up to a 12 month supply of resources and up to a 3 month > supply for resource from the ARIN free pool. Does that jive with your > intent for this policy? > A1: Correct. After we get to the last /8, you can request up to a > 3-month supply from the free pool, but only every 3 months unless you > can document an unforeseen change in circumstances since your last > request. However, if you get the space via transfer, you can get a block > big enough for 12 month's need, and if you end up using it up faster, > you can submit another request after 3 months. > Q2: If I were on the waiting list, and subsequently received a transfer > via 8.3, would I be removed from the waiting list? > A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer > will be considered fulfilled and removed from the waiting list." > Q3: Would receipt of an M&A transfer remove you from the waiting list, too? > A3: I think that depends on how the M&A is justified. If you acquire a > company that is already efficiently utilizing all its IP space, I don't > think that would count toward fulfilling an outstanding need that you > have a request on the waiting list for. However, if your justification > for keeping the space held by the acquired company is that you plan to > use it for new stuff, then that would meet an outstanding need, and a > request for that same need would be considered fulfilled and removed > from the waiting list. > Q4: What about Multiple Discrete Networks? > A4: Allocations and assignments to organizations using the Multiple > Discrete Networks policy must still be made as a single continuous range > of addresses. This preserves future aggregatability of the space, and > ensures fairness between MDN and ordinary requests. > > > > > _______________________________________________ > 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 Thu Jan 28 16:36:37 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 Jan 2010 15:36:37 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <02c701caa054$b71df010$2559d030$@net> References: <02c701caa054$b71df010$2559d030$@net> Message-ID: <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> I agree with and support the AC's decision to abandon Policy proposal 95. Persons (real or artificial) wanting to do business on a public network must be public and reachable. > > I do not feel the AC should abandon Policy Proposal 95: Customer > Confidentiality. I formally petition to move the following text forward > for > discussion on the list and at the next Public Policy Meeting. I would > appreciate it if anyone this policy applies to would support moving this > proposal forward by posting statements in support of the petition to this > list. > > 1. Policy Proposal Name: Customer Confidentiality > > 2. Proposal Originator: Aaron Wendel > > 3. Proposal Version: 2.0 > > 4. Date: 10 June 2009 > > 5. Proposal type: new > > 6. Policy term: permanent > > 7. Policy statement: > > ISPs may choose to enter the customer's name along with the ISP's > address and phone number in reassignments and reallocations in lieu of > the customer's address and phone number. The customer's actual > information must be provided to ARIN on request and will be held in the > strictest confidence. > > 8. Rationale: > > Version 2.0 clarifies the need for the customer name to remain in the > SWIP and RWHOIS information. > > Customer contact lists are one of the most proprietary and confidential > pieces of information in any business. The requirements for ISPs to > publish those lists via SWIP or RWHOIS runs contrary to good business > practices and invites competitors and others to solicit both individuals > and companies receiving reassignments and sub allocations from upstream > providers. > > 9. Timetable for implementation: immediate > > Aaron Wendel > Wholesale Internet, Inc. > 324 E. 11th St. Suite 1000 > Kansas City, MO 64106 > 816-256-3031 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Thu Jan 28 16:46:12 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 Jan 2010 13:46:12 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B6201B6.20604@ipinc.net> References: <4B58AED5.4030705@arin.net> <4B6201B6.20604@ipinc.net> Message-ID: <4B6205A4.6000501@gmail.com> Good point. I wonder if that would be covered by the existing clause that "ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a re-validation of the original request"? If contact fails, then I'd say that re-validation fails as well. Thoughts? I'll go ahead and add a FAQ on this as well. Thanks, Scott On 1/28/2010 1:29 PM, Ted Mittelstaedt wrote: > My only comment to the AC on this is I think that you need to give ARIN > the ability to pull a request off the waiting list if they can no longer > reach the requester. If a request on the list languishes for years, > it may only be satisfied once the Internet has shifted from IPv4 to IPv6 > and orgs are abandoning IPv4 is droves - and at that time if they cannot > reach the requester, it seems that the request will then be in limbo. > > Ted > > Member Services wrote: >> Draft Policy 2010-1 >> Waiting List for Unmet IPv4 Requests >> >> On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting List >> for Unmet IPv4 Requests" as a draft policy for adoption discussion on >> the PPML and at the Public Policy Meeting in Toronto in April. >> >> The draft was developed by the AC from Policy Proposal "97. Waiting List >> for Unmet IPv4 Requests". Per the Policy Development Process the AC >> submitted text to ARIN for a staff and legal assessment prior to its >> selection as a draft policy. Below the draft policy is the ARIN staff >> and legal assessment, including the original proposal text. >> >> Draft Policy 2010-1 is below and can be found at: >> https://www.arin.net/policy/proposals/2010_1.html >> >> You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to >> the April Public Policy Meeting. Both the discussion on the list and >> at the meeting will be used by the ARIN Advisory Council to determine >> the community consensus for adopting this as policy. >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy 2010-1 >> Waiting List for Unmet IPv4 Requests >> >> Version/Date: 21 January 2010 >> >> Policy statement: >> Replace 4.1.6 with: >> >> 4.1.6. Aggregation >> >> In order to preserve aggregation, ARIN attempts to issue blocks of >> addresses on appropriate "CIDR-supported" bit boundaries. As long as >> sufficient space is available, ARIN may reserve space to maximize >> aggregation possibilities. ARIN will make each allocation and assignment >> as a single continuous range of addresses. >> >> Add new section 4.1.8: >> >> 4.1.8 Unmet requests >> >> In the event that ARIN does not have a contiguous block of addresses of >> sufficient size to fulfill a qualified request, ARIN will provide the >> requesting organization with the option to either modify their request >> and request a smaller size block, or be placed on a waiting list of >> pre-qualified recipients. Repeated requests, in a manner that would >> circumvent 4.1.6, are not allowed: an organization may only receive one >> allocation, assignment, or transfer every 3 months, but ARIN, at its >> sole discretion, may waive this requirement if the requester can >> document an unforeseen change in circumstances since their last request. >> Qualified requesters whose request cannot be immediately met will also >> be advised of the availability of the transfer mechanism in section 8.3 >> as an alternative mechanism to obtain IPv4 addresses. >> >> 4.1.8.1 Waiting list >> >> The position of each qualified request on the waiting list will be >> determined by the date it was approved. Each organization may have one >> approved request on the waiting list at a time. >> >> 4.1.8.2 Fulfilling unmet needs >> >> As address blocks become available for allocation, ARIN will fulfill >> requests on a first-approved basis, subject to the size of each >> available address block and a re-validation of the original request. >> Requests will not be partially filled. Any requests met through a >> transfer will be considered fulfilled and removed from the waiting list. >> >> 8. Rationale: >> >> ARIN will soon be unable to meet all approved requests for IPv4 address >> space. In the absence of a policy like this, it is unclear what ARIN >> should do with subsequent requests. >> >> This policy would allocate reclaimed address blocks (and the last of the >> ARIN free pool) on a first-come-first-served basis, while preserving >> aggregation to the degree possible. As the free pool shrinks, requests >> larger than the largest block left would be placed on a waiting list, >> while smaller requests would use up the rest of it, until all requests >> have to go on the waiting list. As additional reclaimed addresses become >> available, the requests that have been waiting the longest would be met >> first. If a requester gets the addresses they need via transfer, then >> they would be removed from the waiting list and would need to wait and >> submit a new request for additional address space, either directly or >> via transfer. >> >> FAQ: >> >> Q1: The effect of 2009-8, if implemented by the Board, is to allow >> transfers to be up to a 12 month supply of resources and up to a 3 month >> supply for resource from the ARIN free pool. Does that jive with your >> intent for this policy? >> >> A1: Correct. After we get to the last /8, you can request up to a >> 3-month supply from the free pool, but only every 3 months unless you >> can document an unforeseen change in circumstances since your last >> request. However, if you get the space via transfer, you can get a block >> big enough for 12 month's need, and if you end up using it up faster, >> you can submit another request after 3 months. >> >> Q2: If I were on the waiting list, and subsequently received a transfer >> via 8.3, would I be removed from the waiting list? >> >> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >> will be considered fulfilled and removed from the waiting list." >> >> Q3: Would receipt of an M&A transfer remove you from the waiting >> list, too? >> >> A3: I think that depends on how the M&A is justified. If you acquire a >> company that is already efficiently utilizing all its IP space, I don't >> think that would count toward fulfilling an outstanding need that you >> have a request on the waiting list for. However, if your justification >> for keeping the space held by the acquired company is that you plan to >> use it for new stuff, then that would meet an outstanding need, and a >> request for that same need would be considered fulfilled and removed >> from the waiting list. >> >> Q4: What about Multiple Discrete Networks? >> >> A4: Allocations and assignments to organizations using the Multiple >> Discrete Networks policy must still be made as a single continuous range >> of addresses. This preserves future aggregatability of the space, and >> ensures fairness between MDN and ordinary requests. >> >> Timetable for implementation: Immediate. >> >> >> ##### >> >> >> STAFF ASSESSMENT >> >> Proposal: Waiting List for Unmet IPv4 Requests >> Proposal Version: Updated by AC and given to staff for assessment on 29 >> Dec 2009 >> >> Date of Assessment: 12 January 2010 >> >> 1. Proposal Summary (Staff Understanding) >> >> Staff understands that this proposal would create a waiting list for >> requestors whose IPv4 address needs cannot be fulfilled by ARIN at the >> time of the request approval. The proposal includes text to prevent >> requestors from gaming the policy's intent by forbidding requestors from >> making multiple requests of a small size and limiting the issuance of >> space to no more than once every 3 months. >> >> 2. Comments >> >> A. ARIN Staff Comments >> >> ? In section 4.1.8, the author says ?Repeated requests, in a manner that >> would circumvent 4.1.6, are not allowed: an organization may only >> receive one allocation, assignment, or transfer every 3 months, but >> ARIN, at its sole discretion, may waive this requirement if the >> requester can document an unforeseen change in circumstances since their >> last request?. >> >> As written, the portion of the policy that starts with ?but ARIN, at its >> sole discretion? gives no concrete criteria for staff to use in its >> assessment of the request. This ?exception clause? is open to >> interpretation and may not be applied consistently by staff if there are >> no guidelines or rules for staff to follow. It essentially allows ARIN >> staff to determine the policy criteria for who can or can?t qualify >> under this waiver. >> >> B. ARIN General Counsel >> >> "At this time counsel has no significant legal comments. Any system to >> order and prioritize requests for resources which may exceed the >> available resources must permit consistent administration by ARIN." >> >> 3. Resource Impact >> >> This policy would have moderate resource impact. It is estimated that >> implementation would occur within 6 months after ratification by the >> ARIN Board of Trustees. The following would be needed in order to >> implement: >> >> ? The development of software to monitor IPv4 returns, a ?waiting list? >> that will include request size as well as minimum size acceptable, and a >> system that will match/compare returns with the waiting list >> ? Modifications to the management web application >> ? Changes to current business processes >> ? Updated guidelines >> ? Staff training >> >> >> >> 4. Proposal Text: Waiting list for unmet IPv4 requests >> >> Replace 4.1.6 with: >> 4.1.6. Aggregation >> In order to preserve aggregation, ARIN attempts to issue blocks of >> addresses on appropriate "CIDR-supported" bit boundaries. As long as >> sufficient space is available, ARIN may reserve space to maximize >> aggregation possibilities. ARIN will make each allocation and assignment >> as a single continuous range of addresses. >> Add new section 4.1.8: >> >> 4.1.8 Unmet requests >> In the event that ARIN does not have a contiguous block of addresses of >> sufficient size to fulfill a qualified request, ARIN will provide the >> requesting organization with the option to either modify their request >> and request a smaller size block, or be placed on a waiting list of >> pre-qualified recipients. Repeated requests, in a manner that would >> circumvent 4.1.6, are not allowed: an organization may only receive one >> allocation, assignment, or transfer every 3 months, but ARIN, at its >> sole discretion, may waive this requirement if the requester can >> document an unforeseen change in circumstances since their last request. >> Qualified requesters whose request cannot be immediately met will also >> be advised of the availability of the transfer mechanism in section 8.3 >> as an alternative mechanism to obtain IPv4 addresses. >> >> 4.1.8.1 Waiting list >> The position of each qualified request on the waiting list will be >> determined by the date it was approved. Each organization may have one >> approved request on the waiting list at a time. >> >> 4.1.8.2 Fulfilling unmet needs >> As address blocks become available for allocation, ARIN will fulfill >> requests on a first-approved basis, subject to the size of each >> available address block and a re-validation of the original request. >> Requests will not be partially filled. Any requests met through a >> transfer will be considered fulfilled and removed from the waiting list. >> >> >> Rationale: >> ARIN will soon be unable to meet all approved requests for IPv4 address >> space. In the absence of a policy like this, it is unclear what ARIN >> should do with subsequent requests. >> This policy would allocate reclaimed address blocks (and the last of the >> ARIN free pool) on a first-come-first-served basis, while preserving >> aggregation to the degree possible. As the free pool shrinks, requests >> larger than the largest block left would be placed on a waiting list, >> while smaller requests would use up the rest of it, until all requests >> have to go on the waiting list. As additional reclaimed addresses become >> available, the requests that have been waiting the longest would be met >> first. If a requester gets the addresses they need via transfer, then >> they would be removed from the waiting list and would need to wait and >> submit a new request for additional address space, either directly or >> via transfer. >> >> >> >> >> FAQ: >> Q1: The effect of 2009-8, if implemented by the Board, is to allow >> transfers to be up to a 12 month supply of resources and up to a 3 month >> supply for resource from the ARIN free pool. Does that jive with your >> intent for this policy? >> A1: Correct. After we get to the last /8, you can request up to a >> 3-month supply from the free pool, but only every 3 months unless you >> can document an unforeseen change in circumstances since your last >> request. However, if you get the space via transfer, you can get a block >> big enough for 12 month's need, and if you end up using it up faster, >> you can submit another request after 3 months. >> Q2: If I were on the waiting list, and subsequently received a transfer >> via 8.3, would I be removed from the waiting list? >> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >> will be considered fulfilled and removed from the waiting list." >> Q3: Would receipt of an M&A transfer remove you from the waiting >> list, too? >> A3: I think that depends on how the M&A is justified. If you acquire a >> company that is already efficiently utilizing all its IP space, I don't >> think that would count toward fulfilling an outstanding need that you >> have a request on the waiting list for. However, if your justification >> for keeping the space held by the acquired company is that you plan to >> use it for new stuff, then that would meet an outstanding need, and a >> request for that same need would be considered fulfilled and removed >> from the waiting list. >> Q4: What about Multiple Discrete Networks? >> A4: Allocations and assignments to organizations using the Multiple >> Discrete Networks policy must still be made as a single continuous range >> of addresses. This preserves future aggregatability of the space, and >> ensures fairness between MDN and ordinary requests. >> >> >> >> >> _______________________________________________ >> 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 info at arin.net Thu Jan 28 17:02:52 2010 From: info at arin.net (Member Services) Date: Thu, 28 Jan 2010 17:02:52 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <02c701caa054$b71df010$2559d030$@net> References: <02c701caa054$b71df010$2559d030$@net> Message-ID: <4B62098C.60606@arin.net> With the message below a petition has started regarding the ARIN Advisory Council's decision to abandon Proposal 95: Customer Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the ARIN Advisory Council (AC) had decided to abandon the proposal. If successful, this petition will change Proposal 95 into a Draft Policy which will be published for discussion and review by the community on the PPML and at the Public Policy Meeting in April. If the petition fails, the proposal will be closed. For this petition to be successful, it will need statements of support from at least 10 different people from 10 different organizations. If you wish to support this petition, post a statement of support to PPML on this thread. Point of contact information is required, either to the entire PPML or with a follow up post to petition at arin.net with full POC information (name, organization, street address, email, phone). The duration of the petition is five business days; it will end on 4 February 2010. ARIN staff will post the result of the petition to PPML. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The proposal text is below and 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, Member Services American Registry for Internet Numbers (ARIN) ##### Aaron Wendel wrote: > I do not feel the AC should abandon Policy Proposal 95: Customer > Confidentiality. I formally petition to move the following text forward for > discussion on the list and at the next Public Policy Meeting. I would > appreciate it if anyone this policy applies to would support moving this > proposal forward by posting statements in support of the petition to this > list. > > 1. Policy Proposal Name: Customer Confidentiality > > 2. Proposal Originator: Aaron Wendel > > 3. Proposal Version: 2.0 > > 4. Date: 10 June 2009 > > 5. Proposal type: new > > 6. Policy term: permanent > > 7. Policy statement: > > ISPs may choose to enter the customer's name along with the ISP's > address and phone number in reassignments and reallocations in lieu of > the customer's address and phone number. The customer's actual > information must be provided to ARIN on request and will be held in the > strictest confidence. > > 8. Rationale: > > Version 2.0 clarifies the need for the customer name to remain in the > SWIP and RWHOIS information. > > Customer contact lists are one of the most proprietary and confidential > pieces of information in any business. The requirements for ISPs to > publish those lists via SWIP or RWHOIS runs contrary to good business > practices and invites competitors and others to solicit both individuals > and companies receiving reassignments and sub allocations from upstream > providers. > > 9. Timetable for implementation: immediate > > Aaron Wendel > Wholesale Internet, Inc. > 324 E. 11th St. Suite 1000 > Kansas City, MO 64106 > 816-256-3031 > > _______________________________________________ > 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 jay at handynetworks.com Thu Jan 28 17:06:30 2010 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Thu, 28 Jan 2010 22:06:30 +0000 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B62098C.60606@arin.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: <1BC378592675E040B37CD2AE7C0A542A635130@OfficeExch2k7A.exchange.handynetworks.com> I support this petition and proposal. Thanks! ----- Jay Sudowski // Handy Networks LLC Director of Technical Services Providing Premium Reseller, Dedicated and Colocation Hosting Solutions Tel: 303-414-6902 |? Fax: 303-414-6912 www.handynetworks.com -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Thursday, January 28, 2010 3:03 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality With the message below a petition has started regarding the ARIN Advisory Council's decision to abandon Proposal 95: Customer Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the ARIN Advisory Council (AC) had decided to abandon the proposal. If successful, this petition will change Proposal 95 into a Draft Policy which will be published for discussion and review by the community on the PPML and at the Public Policy Meeting in April. If the petition fails, the proposal will be closed. For this petition to be successful, it will need statements of support from at least 10 different people from 10 different organizations. If you wish to support this petition, post a statement of support to PPML on this thread. Point of contact information is required, either to the entire PPML or with a follow up post to petition at arin.net with full POC information (name, organization, street address, email, phone). The duration of the petition is five business days; it will end on 4 February 2010. ARIN staff will post the result of the petition to PPML. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The proposal text is below and 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, Member Services American Registry for Internet Numbers (ARIN) ##### Aaron Wendel wrote: > I do not feel the AC should abandon Policy Proposal 95: Customer > Confidentiality. I formally petition to move the following text forward for > discussion on the list and at the next Public Policy Meeting. I would > appreciate it if anyone this policy applies to would support moving this > proposal forward by posting statements in support of the petition to this > list. > > 1. Policy Proposal Name: Customer Confidentiality > > 2. Proposal Originator: Aaron Wendel > > 3. Proposal Version: 2.0 > > 4. Date: 10 June 2009 > > 5. Proposal type: new > > 6. Policy term: permanent > > 7. Policy statement: > > ISPs may choose to enter the customer's name along with the ISP's > address and phone number in reassignments and reallocations in lieu of > the customer's address and phone number. The customer's actual > information must be provided to ARIN on request and will be held in the > strictest confidence. > > 8. Rationale: > > Version 2.0 clarifies the need for the customer name to remain in the > SWIP and RWHOIS information. > > Customer contact lists are one of the most proprietary and confidential > pieces of information in any business. The requirements for ISPs to > publish those lists via SWIP or RWHOIS runs contrary to good business > practices and invites competitors and others to solicit both individuals > and companies receiving reassignments and sub allocations from upstream > providers. > > 9. Timetable for implementation: immediate > > Aaron Wendel > Wholesale Internet, Inc. > 324 E. 11th St. Suite 1000 > Kansas City, MO 64106 > 816-256-3031 > > _______________________________________________ > 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 joe at joesdatacenter.com Thu Jan 28 17:12:37 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Thu, 28 Jan 2010 16:12:37 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B62098C.60606@arin.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: <38dd4e411001281412u10a2729ardd528bbc924df398@mail.gmail.com> I would like to register my support for this petition. Joe Morgan Joe's Datacenter, LLC 877-Joe-Data On Thu, Jan 28, 2010 at 4:02 PM, Member Services wrote: > With the message below a petition has started regarding the ARIN > Advisory Council's decision to abandon Proposal 95: Customer > Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the > ARIN Advisory Council (AC) had decided to abandon the proposal. > > If successful, this petition will change Proposal 95 into a Draft Policy > which will be published for discussion and review by the community on > the PPML and at the Public Policy Meeting in April. If the petition > fails, the proposal will be closed. > > For this petition to be successful, it will need statements of support > from at least 10 different people from 10 different organizations. If > you wish to support this petition, post a statement of support to PPML > on this thread. Point of contact information is required, either to the > entire PPML or with a follow up post to petition at arin.net with full POC > information (name, organization, street address, email, phone). > > The duration of the petition is five business days; it will end on 4 > February 2010. ARIN staff will post the result of the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Member Services > American Registry for Internet Numbers (ARIN) > > ##### > > Aaron Wendel wrote: >> >> I do not feel the AC should abandon Policy Proposal 95: Customer >> Confidentiality. I formally petition to move the following text forward >> for >> discussion on the list and at the next Public Policy Meeting. I would >> appreciate it if anyone this policy applies to would support moving this >> proposal forward by posting statements in support of the petition to this >> list. >> >> 1. Policy Proposal Name: Customer Confidentiality >> >> 2. Proposal Originator: Aaron Wendel >> >> 3. Proposal Version: 2.0 >> >> 4. Date: 10 June 2009 >> >> 5. Proposal type: new >> >> 6. Policy term: permanent >> >> 7. Policy statement: >> >> ISPs may choose to enter the customer's name along with the ISP's >> address and phone number in reassignments and reallocations in lieu of >> the customer's address and phone number. ?The customer's actual >> information must be provided to ARIN on request and will be held in the >> strictest confidence. >> >> 8. Rationale: >> >> Version 2.0 clarifies the need for the customer name to remain in the >> SWIP and RWHOIS information. >> >> Customer contact lists are one of the most proprietary and confidential >> pieces of information in any business. ?The requirements for ISPs to >> publish those lists via SWIP or RWHOIS runs contrary to good business >> practices and invites competitors and others to solicit both individuals >> and companies receiving reassignments and sub allocations from upstream >> providers. >> >> 9. Timetable for implementation: immediate >> >> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. ?Suite 1000 >> Kansas City, MO 64106 >> 816-256-3031 >> >> _______________________________________________ >> 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. > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From admin at scratchtelecom.com Thu Jan 28 17:12:58 2010 From: admin at scratchtelecom.com (admin at scratchtelecom.com) Date: Thu, 28 Jan 2010 17:12:58 -0500 Subject: [arin-ppml] Proposal 95 petition Message-ID: <20100128171258.2oabmsf6s40ocs8w@host4.scratchtelecom.com> Scratch Telecom supports the petition to advance proposal 95. Scratch Telecom AS36676 OrgID: SCRAT-ARIN From tedm at ipinc.net Thu Jan 28 17:30:04 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 14:30:04 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B6205A4.6000501@gmail.com> References: <4B58AED5.4030705@arin.net> <4B6201B6.20604@ipinc.net> <4B6205A4.6000501@gmail.com> Message-ID: <4B620FEC.6000009@ipinc.net> Scott Leibrand wrote: > Good point. I wonder if that would be covered by the existing clause > that "ARIN will fulfill requests on a first-approved basis, subject to > the size of each available address block and a re-validation of the > original request"? Oops, I didn't notice that. > If contact fails, then I'd say that re-validation > fails as well. > Yup. > Thoughts? > Well, other than the obvious thought that I can just see some prankster putting in a /8 request, with justification, after runout, just for the fun of it. Ted > I'll go ahead and add a FAQ on this as well. > > Thanks, > Scott > > On 1/28/2010 1:29 PM, Ted Mittelstaedt wrote: >> My only comment to the AC on this is I think that you need to give ARIN >> the ability to pull a request off the waiting list if they can no longer >> reach the requester. If a request on the list languishes for years, >> it may only be satisfied once the Internet has shifted from IPv4 to IPv6 >> and orgs are abandoning IPv4 is droves - and at that time if they cannot >> reach the requester, it seems that the request will then be in limbo. >> >> Ted >> >> Member Services wrote: >>> Draft Policy 2010-1 >>> Waiting List for Unmet IPv4 Requests >>> >>> On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting List >>> for Unmet IPv4 Requests" as a draft policy for adoption discussion on >>> the PPML and at the Public Policy Meeting in Toronto in April. >>> >>> The draft was developed by the AC from Policy Proposal "97. Waiting List >>> for Unmet IPv4 Requests". Per the Policy Development Process the AC >>> submitted text to ARIN for a staff and legal assessment prior to its >>> selection as a draft policy. Below the draft policy is the ARIN staff >>> and legal assessment, including the original proposal text. >>> >>> Draft Policy 2010-1 is below and can be found at: >>> https://www.arin.net/policy/proposals/2010_1.html >>> >>> You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to >>> the April Public Policy Meeting. Both the discussion on the list and >>> at the meeting will be used by the ARIN Advisory Council to determine >>> the community consensus for adopting this as policy. >>> >>> The ARIN Policy Development Process can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> Draft Policy 2010-1 >>> Waiting List for Unmet IPv4 Requests >>> >>> Version/Date: 21 January 2010 >>> >>> Policy statement: >>> Replace 4.1.6 with: >>> >>> 4.1.6. Aggregation >>> >>> In order to preserve aggregation, ARIN attempts to issue blocks of >>> addresses on appropriate "CIDR-supported" bit boundaries. As long as >>> sufficient space is available, ARIN may reserve space to maximize >>> aggregation possibilities. ARIN will make each allocation and assignment >>> as a single continuous range of addresses. >>> >>> Add new section 4.1.8: >>> >>> 4.1.8 Unmet requests >>> >>> In the event that ARIN does not have a contiguous block of addresses of >>> sufficient size to fulfill a qualified request, ARIN will provide the >>> requesting organization with the option to either modify their request >>> and request a smaller size block, or be placed on a waiting list of >>> pre-qualified recipients. Repeated requests, in a manner that would >>> circumvent 4.1.6, are not allowed: an organization may only receive one >>> allocation, assignment, or transfer every 3 months, but ARIN, at its >>> sole discretion, may waive this requirement if the requester can >>> document an unforeseen change in circumstances since their last request. >>> Qualified requesters whose request cannot be immediately met will also >>> be advised of the availability of the transfer mechanism in section 8.3 >>> as an alternative mechanism to obtain IPv4 addresses. >>> >>> 4.1.8.1 Waiting list >>> >>> The position of each qualified request on the waiting list will be >>> determined by the date it was approved. Each organization may have one >>> approved request on the waiting list at a time. >>> >>> 4.1.8.2 Fulfilling unmet needs >>> >>> As address blocks become available for allocation, ARIN will fulfill >>> requests on a first-approved basis, subject to the size of each >>> available address block and a re-validation of the original request. >>> Requests will not be partially filled. Any requests met through a >>> transfer will be considered fulfilled and removed from the waiting list. >>> >>> 8. Rationale: >>> >>> ARIN will soon be unable to meet all approved requests for IPv4 address >>> space. In the absence of a policy like this, it is unclear what ARIN >>> should do with subsequent requests. >>> >>> This policy would allocate reclaimed address blocks (and the last of the >>> ARIN free pool) on a first-come-first-served basis, while preserving >>> aggregation to the degree possible. As the free pool shrinks, requests >>> larger than the largest block left would be placed on a waiting list, >>> while smaller requests would use up the rest of it, until all requests >>> have to go on the waiting list. As additional reclaimed addresses become >>> available, the requests that have been waiting the longest would be met >>> first. If a requester gets the addresses they need via transfer, then >>> they would be removed from the waiting list and would need to wait and >>> submit a new request for additional address space, either directly or >>> via transfer. >>> >>> FAQ: >>> >>> Q1: The effect of 2009-8, if implemented by the Board, is to allow >>> transfers to be up to a 12 month supply of resources and up to a 3 month >>> supply for resource from the ARIN free pool. Does that jive with your >>> intent for this policy? >>> >>> A1: Correct. After we get to the last /8, you can request up to a >>> 3-month supply from the free pool, but only every 3 months unless you >>> can document an unforeseen change in circumstances since your last >>> request. However, if you get the space via transfer, you can get a block >>> big enough for 12 month's need, and if you end up using it up faster, >>> you can submit another request after 3 months. >>> >>> Q2: If I were on the waiting list, and subsequently received a transfer >>> via 8.3, would I be removed from the waiting list? >>> >>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >>> will be considered fulfilled and removed from the waiting list." >>> >>> Q3: Would receipt of an M&A transfer remove you from the waiting >>> list, too? >>> >>> A3: I think that depends on how the M&A is justified. If you acquire a >>> company that is already efficiently utilizing all its IP space, I don't >>> think that would count toward fulfilling an outstanding need that you >>> have a request on the waiting list for. However, if your justification >>> for keeping the space held by the acquired company is that you plan to >>> use it for new stuff, then that would meet an outstanding need, and a >>> request for that same need would be considered fulfilled and removed >>> from the waiting list. >>> >>> Q4: What about Multiple Discrete Networks? >>> >>> A4: Allocations and assignments to organizations using the Multiple >>> Discrete Networks policy must still be made as a single continuous range >>> of addresses. This preserves future aggregatability of the space, and >>> ensures fairness between MDN and ordinary requests. >>> >>> Timetable for implementation: Immediate. >>> >>> >>> ##### >>> >>> >>> STAFF ASSESSMENT >>> >>> Proposal: Waiting List for Unmet IPv4 Requests >>> Proposal Version: Updated by AC and given to staff for assessment on 29 >>> Dec 2009 >>> >>> Date of Assessment: 12 January 2010 >>> >>> 1. Proposal Summary (Staff Understanding) >>> >>> Staff understands that this proposal would create a waiting list for >>> requestors whose IPv4 address needs cannot be fulfilled by ARIN at the >>> time of the request approval. The proposal includes text to prevent >>> requestors from gaming the policy's intent by forbidding requestors from >>> making multiple requests of a small size and limiting the issuance of >>> space to no more than once every 3 months. >>> >>> 2. Comments >>> >>> A. ARIN Staff Comments >>> >>> ? In section 4.1.8, the author says ?Repeated requests, in a manner that >>> would circumvent 4.1.6, are not allowed: an organization may only >>> receive one allocation, assignment, or transfer every 3 months, but >>> ARIN, at its sole discretion, may waive this requirement if the >>> requester can document an unforeseen change in circumstances since their >>> last request?. >>> >>> As written, the portion of the policy that starts with ?but ARIN, at its >>> sole discretion? gives no concrete criteria for staff to use in its >>> assessment of the request. This ?exception clause? is open to >>> interpretation and may not be applied consistently by staff if there are >>> no guidelines or rules for staff to follow. It essentially allows ARIN >>> staff to determine the policy criteria for who can or can?t qualify >>> under this waiver. >>> >>> B. ARIN General Counsel >>> >>> "At this time counsel has no significant legal comments. Any system to >>> order and prioritize requests for resources which may exceed the >>> available resources must permit consistent administration by ARIN." >>> >>> 3. Resource Impact >>> >>> This policy would have moderate resource impact. It is estimated that >>> implementation would occur within 6 months after ratification by the >>> ARIN Board of Trustees. The following would be needed in order to >>> implement: >>> >>> ? The development of software to monitor IPv4 returns, a ?waiting list? >>> that will include request size as well as minimum size acceptable, and a >>> system that will match/compare returns with the waiting list >>> ? Modifications to the management web application >>> ? Changes to current business processes >>> ? Updated guidelines >>> ? Staff training >>> >>> >>> >>> 4. Proposal Text: Waiting list for unmet IPv4 requests >>> >>> Replace 4.1.6 with: >>> 4.1.6. Aggregation >>> In order to preserve aggregation, ARIN attempts to issue blocks of >>> addresses on appropriate "CIDR-supported" bit boundaries. As long as >>> sufficient space is available, ARIN may reserve space to maximize >>> aggregation possibilities. ARIN will make each allocation and assignment >>> as a single continuous range of addresses. >>> Add new section 4.1.8: >>> >>> 4.1.8 Unmet requests >>> In the event that ARIN does not have a contiguous block of addresses of >>> sufficient size to fulfill a qualified request, ARIN will provide the >>> requesting organization with the option to either modify their request >>> and request a smaller size block, or be placed on a waiting list of >>> pre-qualified recipients. Repeated requests, in a manner that would >>> circumvent 4.1.6, are not allowed: an organization may only receive one >>> allocation, assignment, or transfer every 3 months, but ARIN, at its >>> sole discretion, may waive this requirement if the requester can >>> document an unforeseen change in circumstances since their last request. >>> Qualified requesters whose request cannot be immediately met will also >>> be advised of the availability of the transfer mechanism in section 8.3 >>> as an alternative mechanism to obtain IPv4 addresses. >>> >>> 4.1.8.1 Waiting list >>> The position of each qualified request on the waiting list will be >>> determined by the date it was approved. Each organization may have one >>> approved request on the waiting list at a time. >>> >>> 4.1.8.2 Fulfilling unmet needs >>> As address blocks become available for allocation, ARIN will fulfill >>> requests on a first-approved basis, subject to the size of each >>> available address block and a re-validation of the original request. >>> Requests will not be partially filled. Any requests met through a >>> transfer will be considered fulfilled and removed from the waiting list. >>> >>> >>> Rationale: >>> ARIN will soon be unable to meet all approved requests for IPv4 address >>> space. In the absence of a policy like this, it is unclear what ARIN >>> should do with subsequent requests. >>> This policy would allocate reclaimed address blocks (and the last of the >>> ARIN free pool) on a first-come-first-served basis, while preserving >>> aggregation to the degree possible. As the free pool shrinks, requests >>> larger than the largest block left would be placed on a waiting list, >>> while smaller requests would use up the rest of it, until all requests >>> have to go on the waiting list. As additional reclaimed addresses become >>> available, the requests that have been waiting the longest would be met >>> first. If a requester gets the addresses they need via transfer, then >>> they would be removed from the waiting list and would need to wait and >>> submit a new request for additional address space, either directly or >>> via transfer. >>> >>> >>> >>> >>> FAQ: >>> Q1: The effect of 2009-8, if implemented by the Board, is to allow >>> transfers to be up to a 12 month supply of resources and up to a 3 month >>> supply for resource from the ARIN free pool. Does that jive with your >>> intent for this policy? >>> A1: Correct. After we get to the last /8, you can request up to a >>> 3-month supply from the free pool, but only every 3 months unless you >>> can document an unforeseen change in circumstances since your last >>> request. However, if you get the space via transfer, you can get a block >>> big enough for 12 month's need, and if you end up using it up faster, >>> you can submit another request after 3 months. >>> Q2: If I were on the waiting list, and subsequently received a transfer >>> via 8.3, would I be removed from the waiting list? >>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >>> will be considered fulfilled and removed from the waiting list." >>> Q3: Would receipt of an M&A transfer remove you from the waiting >>> list, too? >>> A3: I think that depends on how the M&A is justified. If you acquire a >>> company that is already efficiently utilizing all its IP space, I don't >>> think that would count toward fulfilling an outstanding need that you >>> have a request on the waiting list for. However, if your justification >>> for keeping the space held by the acquired company is that you plan to >>> use it for new stuff, then that would meet an outstanding need, and a >>> request for that same need would be considered fulfilled and removed >>> from the waiting list. >>> Q4: What about Multiple Discrete Networks? >>> A4: Allocations and assignments to organizations using the Multiple >>> Discrete Networks policy must still be made as a single continuous range >>> of addresses. This preserves future aggregatability of the space, and >>> ensures fairness between MDN and ordinary requests. >>> >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bill at herrin.us Thu Jan 28 17:30:07 2010 From: bill at herrin.us (William Herrin) Date: Thu, 28 Jan 2010 17:30:07 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <02c701caa054$b71df010$2559d030$@net> References: <02c701caa054$b71df010$2559d030$@net> Message-ID: <3c3e3fca1001281430s36e59878sc1d10689020226a@mail.gmail.com> On Thu, Jan 28, 2010 at 3:01 PM, Aaron Wendel wrote: > I do not feel the AC should abandon Policy Proposal 95: Customer > Confidentiality. I formally petition to move the following text forward for In abandoning proposal 95, the AC said: "The Advisory Council concluded that this proposal closely duplicates one recently presented before the community. The community vetted the earlier proposal at a Public Policy Meeting and on PPML in great detail resulting in the proposal failing to gain enough support to move forward in the Policy Development Process (PDP)." Which proposal was that, at which meeting and what was the count during the consensus call? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Thu Jan 28 17:32:13 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 Jan 2010 14:32:13 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B620FEC.6000009@ipinc.net> References: <4B58AED5.4030705@arin.net> <4B6201B6.20604@ipinc.net> <4B6205A4.6000501@gmail.com> <4B620FEC.6000009@ipinc.net> Message-ID: <4B62106D.5070706@gmail.com> On 1/28/2010 2:30 PM, Ted Mittelstaedt wrote: > >> Thoughts? > > Well, other than the obvious thought that I can just see some > prankster putting in a /8 request, with justification, after runout, > just for the fun of it. Heh. I guess he can be a waiting list of 1 then. :-) -Scott From tedm at ipinc.net Thu Jan 28 17:35:00 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 14:35:00 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> Message-ID: <4B621114.3050808@ipinc.net> Kevin Kargel wrote: > I agree with and support the AC's decision to abandon Policy proposal 95. > So do I, but I would suggest that anyone opposed DO NOT respond to this. All your doing is re-opening the discussion again which is, of course, exactly what the submitter wants. Ted From scottleibrand at gmail.com Thu Jan 28 17:42:24 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 Jan 2010 14:42:24 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B621114.3050808@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> Message-ID: <4B6212D0.4000404@gmail.com> On 1/28/2010 2:35 PM, Ted Mittelstaedt wrote: > Kevin Kargel wrote: >> I agree with and support the AC's decision to abandon Policy proposal >> 95. >> > > So do I, but I would suggest that anyone opposed DO NOT respond to > this. All your doing is re-opening the discussion again which is, > of course, exactly what the submitter wants. I voted to abandon this proposal, but IMO it's still perfectly valid to discuss the issue here on PPML. Specifically, the question at hand is whether to make this proposal a draft policy and discuss it at the face-to-face public policy meeting in Toronto. The AC gave our opinion, and now it's up to the community to petition to advance the proposal if enough of you disagree with the AC on the matter. This is also the first use of the petition process under the new PDP, so I'm hoping to see the process run smoothly, whatever the outcome. -Scott From joe at joesdatacenter.com Thu Jan 28 18:04:53 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Thu, 28 Jan 2010 17:04:53 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B6212D0.4000404@gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> Message-ID: <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> That is really not the point of this proposal. The point is that I should not have to give up my entire customer list to my competitors. If somebody is having problems with a company doing business under my IP space then there is no reason why they cant contact my arin abuse poc. I would rather those go to me than to the customer that can just ignore it. I already have problems with people sending complaints to the wrong places and I never even get contacted with the abuse complaint. I don't understand as arin can request the information why does it need to be open to the public? On Thu, Jan 28, 2010 at 4:42 PM, Scott Leibrand wrote: > On 1/28/2010 2:35 PM, Ted Mittelstaedt wrote: >> >> Kevin Kargel wrote: >>> >>> I agree with and support the AC's decision to abandon Policy proposal 95. >>> >> >> So do I, but I would suggest that anyone opposed DO NOT respond to >> this. ?All your doing is re-opening the discussion again which is, >> of course, exactly what the submitter wants. > > I voted to abandon this proposal, but IMO it's still perfectly valid to > discuss the issue here on PPML. ?Specifically, the question at hand is > whether to make this proposal a draft policy and discuss it at the > face-to-face public policy meeting in Toronto. ?The AC gave our opinion, and > now it's up to the community to petition to advance the proposal if enough > of you disagree with the AC on the matter. > > This is also the first use of the petition process under the new PDP, so I'm > hoping to see the process run smoothly, whatever the outcome. > > -Scott > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From tedm at ipinc.net Thu Jan 28 18:07:11 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 15:07:11 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <3c3e3fca1001281430s36e59878sc1d10689020226a@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <3c3e3fca1001281430s36e59878sc1d10689020226a@mail.gmail.com> Message-ID: <4B62189F.6010300@ipinc.net> William Herrin wrote: > On Thu, Jan 28, 2010 at 3:01 PM, Aaron Wendel > wrote: >> I do not feel the AC should abandon Policy Proposal 95: Customer >> Confidentiality. I formally petition to move the following text forward for > > In abandoning proposal 95, the AC said: > > "The Advisory Council concluded that this proposal closely duplicates > one recently presented before the community. The community vetted the > earlier proposal at a Public Policy Meeting and on PPML in great detail > resulting in the proposal failing to gain enough support to move forward > in the Policy Development Process (PDP)." > > Which proposal was that, I would assume proposal 2004-6, it's basically identical. Ted From tedm at ipinc.net Thu Jan 28 18:12:41 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Jan 2010 15:12:41 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> Message-ID: <4B6219E9.6030903@ipinc.net> Joe Morgan wrote: > That is really not the point of this proposal. The point is that I > should not have to give up my entire customer list to my competitors. > If somebody is having problems with a company doing business under my > IP space then there is no reason why they cant contact my arin abuse > poc. I would rather those go to me than to the customer that can just > ignore it. I already have problems with people sending complaints to > the wrong places and I never even get contacted with the abuse > complaint. I don't understand as arin can request the information why > does it need to be open to the public? > Joe, Review the following: http://lists.arin.net/pipermail/arin-ppml/2004-October/002812.html Just keep clicking Next at the top to read all the postings on this thread. Your question is answered there. Ted From aaron at wholesaleinternet.net Thu Jan 28 18:13:53 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 28 Jan 2010 17:13:53 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B62189F.6010300@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <3c3e3fca1001281430s36e59878sc1d10689020226a@mail.gmail.com> <4B62189F.6010300@ipinc.net> Message-ID: <039201caa06f$8edafa10$ac90ee30$@net> I hope not. I would feel slighted if the AC dumped my proposal because they feel 6 years ago is "recently". Aaron -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Thursday, January 28, 2010 5:07 PM To: William Herrin Cc: Aaron Wendel; ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality William Herrin wrote: > On Thu, Jan 28, 2010 at 3:01 PM, Aaron Wendel > wrote: >> I do not feel the AC should abandon Policy Proposal 95: Customer >> Confidentiality. I formally petition to move the following text forward for > > In abandoning proposal 95, the AC said: > > "The Advisory Council concluded that this proposal closely duplicates > one recently presented before the community. The community vetted the > earlier proposal at a Public Policy Meeting and on PPML in great detail > resulting in the proposal failing to gain enough support to move forward > in the Policy Development Process (PDP)." > > Which proposal was that, I would assume proposal 2004-6, it's basically identical. Ted No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 01:36:00 From steve at ibctech.ca Thu Jan 28 18:41:15 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 18:41:15 -0500 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B61C0D5.4070900@gmail.com> References: <28E139F46D45AF49A31950F88C49745804FAA19B@E03MVZ2-UKDY.domain1.systemhost.net> <4B61C0D5.4070900@gmail.com> Message-ID: <4B62209B.8070708@ibctech.ca> Scott Leibrand wrote: > On 1/28/2010 7:18 AM, michael.dillon at bt.com wrote: >> >> I gather you would rather see a system where people apply to >> ARIN once, demonstrate their need once, and get their choice >> of whatever addresses are on the shelf, >> or a chit to be used when they find addresses in the market, >> or a place in a waiting list for reclaimed addresses on the shelf, >> or some combination of the three. >> >> Let's see, little ISP needs a /22 and applies to ARIN. They are >> approved but there is only one /24 on the shelf. Little ISP >> says, we'll take it, plus a chit for another /24, plus a place >> in the queue for two more /24s. If they are unhappy with the >> results of their market search, ARIN lets them exchange the >> chit for another place in the queue, behind their original >> queue postion for two /24s. >> > > That's similar to what I'm proposing, but 2010-1's process is actually > slightly simpler: the ISP can either take the /24, and go away for 3 > months, or they can get in line for a /22 or a /23. They can't be in > multiple places in multiple lines, so "place in the queue" and "chit" > reduce to the exact same thing. > >> That could work. How could it be done with a simple policy that >> doesn't overmanage the situation? >> > > Please feel free to write it up, so we can do a direct apples-to-apples > comparison. Or, if you prefer, feel free to point out which parts of > 2010-1 are overly complicated and should be simplified or eliminated. Why not remove the clause language entirely, get rid of all queues, and just state that the requester can take the largest block available that is smaller than what can be justified at the current time, if what they request is not currently available. Then, no coming back for three months...period. If they want to hold out and re-apply each week, fine. Either ARIN has the block shelved, or they don't. If the policy was as such, would this not a) alleviate administration overhead, and b) force networks to really evaluate where they can recoup space from, if they need it that badly? I mean, we're talking about /22 and less here from what I can tell. There was a lot of feedback (on and off list) to my recent posts that brought human nature into the picture, as well as the non-desire for both added ARIN administration and/or having to have the community consent to each alloc/assignment. I completely understand both points. How do people feel about getting rid of all of that, and just making it clear as to what people will get when the time comes, without any line to wait in? It would save one heck of a lot of overhead from ARIN's perspective. Steve From kkargel at polartel.com Thu Jan 28 18:50:07 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 Jan 2010 17:50:07 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> Message-ID: <8695009A81378E48879980039EEDAD28876D3F7C@MAIL1.polartel.local> > > That is really not the point of this proposal. The point is that I > should not have to give up my entire customer list to my competitors. > If somebody is having problems with a company doing business under my > IP space then there is no reason why they cant contact my arin abuse > poc. I would rather those go to me than to the customer that can just > ignore it. I already have problems with people sending complaints to > the wrong places and I never even get contacted with the abuse > complaint. I don't understand as arin can request the information why > does it need to be open to the public? I will agree with what you are saying insofar as that you should be able to act as PoC for your customer so long as you will be reachable and capable of doing something about issues in a reasonable time. If you are no more than a reseller who has no technical responsibility for the customers' network then I disagree. The problem I have is that when there is a serious and immediate problem that resolution of the problem can be delayed greatly if I have to contact a third order representative who then has to contact a second order representative who then has to contact the end user. It can be days or weeks before I am able to wend through the maze of contacts. I maintain that at a minimum the abuse contact should be a real person who has the power and authority to resolve network issues, not just someone who knows someone who knows how to contact someone who can get hold of the admin. I would go so far as to say that company information could be anonymized so long as the abuse PoC is a live and responsive and authoritative contact. If you are managing the network for your customer then are you not in reality the proper PoC? I also think this should be an option at the end customers' direction. They, not you, should make the determination of what PoC information is entered. Can they not already designate you as their agent? I have as my customers companies who are technically illiterate and who properly and appropriately contract out their network operations to a single local tech house. IMHO that tech house should be the abuse PoC for all of those companies. I don't care who the IP address is assigned to. I do care who the tech admin is that is assigned to the IP address. > > On Thu, Jan 28, 2010 at 4:42 PM, Scott Leibrand > wrote: > > On 1/28/2010 2:35 PM, Ted Mittelstaedt wrote: > >> > >> Kevin Kargel wrote: > >>> > >>> I agree with and support the AC's decision to abandon Policy proposal > 95. > >>> > >> > >> So do I, but I would suggest that anyone opposed DO NOT respond to > >> this. ?All your doing is re-opening the discussion again which is, > >> of course, exactly what the submitter wants. > > > > I voted to abandon this proposal, but IMO it's still perfectly valid to > > discuss the issue here on PPML. ?Specifically, the question at hand is > > whether to make this proposal a draft policy and discuss it at the > > face-to-face public policy meeting in Toronto. ?The AC gave our opinion, > and > > now it's up to the community to petition to advance the proposal if > enough > > of you disagree with the AC on the matter. > > > > This is also the first use of the petition process under the new PDP, so > I'm > > hoping to see the process run smoothly, whatever the outcome. > > > > -Scott > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > -- > Thank You, > Joe Morgan > Joe's Datacenter, LLC > http://joesdatacenter.com > _______________________________________________ > 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 farmer at umn.edu Thu Jan 28 19:00:33 2010 From: farmer at umn.edu (David Farmer) Date: Thu, 28 Jan 2010 18:00:33 -0600 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B6205A4.6000501@gmail.com> References: <4B58AED5.4030705@arin.net> <4B6201B6.20604@ipinc.net> <4B6205A4.6000501@gmail.com> Message-ID: <4B622521.5000204@umn.edu> Scott Leibrand wrote: > Good point. I wonder if that would be covered by the existing clause > that "ARIN will fulfill requests on a first-approved basis, subject to > the size of each available address block and a re-validation of the > original request"? If contact fails, then I'd say that re-validation > fails as well. > > Thoughts? That should take care of part of it but maybe there should be a limit on the time someone who is one the waiting list has to respond, so that the resources can get allocated to the next person on the list, if they are not responding. I would want resource tied up too long while ARIN is trying to contact someone and fails, some small number of days something in the range of 2 to 5 business days would seem reasonable to move on to the next guy. Also, I think a quarterly check with those on the waiting list would be reasonable too. Basically an email asking do they want to remain on the waiting list, if they don't respond within some time frame they can be removed from the list. If they don't want to be bothered then they don't have to be on the list do they. > I'll go ahead and add a FAQ on this as well. > > Thanks, > Scott > > On 1/28/2010 1:29 PM, Ted Mittelstaedt wrote: >> My only comment to the AC on this is I think that you need to give ARIN >> the ability to pull a request off the waiting list if they can no longer >> reach the requester. If a request on the list languishes for years, >> it may only be satisfied once the Internet has shifted from IPv4 to IPv6 >> and orgs are abandoning IPv4 is droves - and at that time if they cannot >> reach the requester, it seems that the request will then be in limbo. >> >> Ted >> >> Member Services wrote: >>> Draft Policy 2010-1 >>> Waiting List for Unmet IPv4 Requests >>> >>> On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting List >>> for Unmet IPv4 Requests" as a draft policy for adoption discussion on >>> the PPML and at the Public Policy Meeting in Toronto in April. >>> >>> The draft was developed by the AC from Policy Proposal "97. Waiting List >>> for Unmet IPv4 Requests". Per the Policy Development Process the AC >>> submitted text to ARIN for a staff and legal assessment prior to its >>> selection as a draft policy. Below the draft policy is the ARIN staff >>> and legal assessment, including the original proposal text. >>> >>> Draft Policy 2010-1 is below and can be found at: >>> https://www.arin.net/policy/proposals/2010_1.html >>> >>> You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to >>> the April Public Policy Meeting. Both the discussion on the list and >>> at the meeting will be used by the ARIN Advisory Council to determine >>> the community consensus for adopting this as policy. >>> >>> The ARIN Policy Development Process can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> Draft Policy 2010-1 >>> Waiting List for Unmet IPv4 Requests >>> >>> Version/Date: 21 January 2010 >>> >>> Policy statement: >>> Replace 4.1.6 with: >>> >>> 4.1.6. Aggregation >>> >>> In order to preserve aggregation, ARIN attempts to issue blocks of >>> addresses on appropriate "CIDR-supported" bit boundaries. As long as >>> sufficient space is available, ARIN may reserve space to maximize >>> aggregation possibilities. ARIN will make each allocation and assignment >>> as a single continuous range of addresses. >>> >>> Add new section 4.1.8: >>> >>> 4.1.8 Unmet requests >>> >>> In the event that ARIN does not have a contiguous block of addresses of >>> sufficient size to fulfill a qualified request, ARIN will provide the >>> requesting organization with the option to either modify their request >>> and request a smaller size block, or be placed on a waiting list of >>> pre-qualified recipients. Repeated requests, in a manner that would >>> circumvent 4.1.6, are not allowed: an organization may only receive one >>> allocation, assignment, or transfer every 3 months, but ARIN, at its >>> sole discretion, may waive this requirement if the requester can >>> document an unforeseen change in circumstances since their last request. >>> Qualified requesters whose request cannot be immediately met will also >>> be advised of the availability of the transfer mechanism in section 8.3 >>> as an alternative mechanism to obtain IPv4 addresses. >>> >>> 4.1.8.1 Waiting list >>> >>> The position of each qualified request on the waiting list will be >>> determined by the date it was approved. Each organization may have one >>> approved request on the waiting list at a time. >>> >>> 4.1.8.2 Fulfilling unmet needs >>> >>> As address blocks become available for allocation, ARIN will fulfill >>> requests on a first-approved basis, subject to the size of each >>> available address block and a re-validation of the original request. >>> Requests will not be partially filled. Any requests met through a >>> transfer will be considered fulfilled and removed from the waiting list. >>> >>> 8. Rationale: >>> >>> ARIN will soon be unable to meet all approved requests for IPv4 address >>> space. In the absence of a policy like this, it is unclear what ARIN >>> should do with subsequent requests. >>> >>> This policy would allocate reclaimed address blocks (and the last of the >>> ARIN free pool) on a first-come-first-served basis, while preserving >>> aggregation to the degree possible. As the free pool shrinks, requests >>> larger than the largest block left would be placed on a waiting list, >>> while smaller requests would use up the rest of it, until all requests >>> have to go on the waiting list. As additional reclaimed addresses become >>> available, the requests that have been waiting the longest would be met >>> first. If a requester gets the addresses they need via transfer, then >>> they would be removed from the waiting list and would need to wait and >>> submit a new request for additional address space, either directly or >>> via transfer. >>> >>> FAQ: >>> >>> Q1: The effect of 2009-8, if implemented by the Board, is to allow >>> transfers to be up to a 12 month supply of resources and up to a 3 month >>> supply for resource from the ARIN free pool. Does that jive with your >>> intent for this policy? >>> >>> A1: Correct. After we get to the last /8, you can request up to a >>> 3-month supply from the free pool, but only every 3 months unless you >>> can document an unforeseen change in circumstances since your last >>> request. However, if you get the space via transfer, you can get a block >>> big enough for 12 month's need, and if you end up using it up faster, >>> you can submit another request after 3 months. >>> >>> Q2: If I were on the waiting list, and subsequently received a transfer >>> via 8.3, would I be removed from the waiting list? >>> >>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >>> will be considered fulfilled and removed from the waiting list." >>> >>> Q3: Would receipt of an M&A transfer remove you from the waiting >>> list, too? >>> >>> A3: I think that depends on how the M&A is justified. If you acquire a >>> company that is already efficiently utilizing all its IP space, I don't >>> think that would count toward fulfilling an outstanding need that you >>> have a request on the waiting list for. However, if your justification >>> for keeping the space held by the acquired company is that you plan to >>> use it for new stuff, then that would meet an outstanding need, and a >>> request for that same need would be considered fulfilled and removed >>> from the waiting list. >>> >>> Q4: What about Multiple Discrete Networks? >>> >>> A4: Allocations and assignments to organizations using the Multiple >>> Discrete Networks policy must still be made as a single continuous range >>> of addresses. This preserves future aggregatability of the space, and >>> ensures fairness between MDN and ordinary requests. >>> >>> Timetable for implementation: Immediate. >>> >>> >>> ##### >>> >>> >>> STAFF ASSESSMENT >>> >>> Proposal: Waiting List for Unmet IPv4 Requests >>> Proposal Version: Updated by AC and given to staff for assessment on 29 >>> Dec 2009 >>> >>> Date of Assessment: 12 January 2010 >>> >>> 1. Proposal Summary (Staff Understanding) >>> >>> Staff understands that this proposal would create a waiting list for >>> requestors whose IPv4 address needs cannot be fulfilled by ARIN at the >>> time of the request approval. The proposal includes text to prevent >>> requestors from gaming the policy's intent by forbidding requestors from >>> making multiple requests of a small size and limiting the issuance of >>> space to no more than once every 3 months. >>> >>> 2. Comments >>> >>> A. ARIN Staff Comments >>> >>> ? In section 4.1.8, the author says ?Repeated requests, in a manner that >>> would circumvent 4.1.6, are not allowed: an organization may only >>> receive one allocation, assignment, or transfer every 3 months, but >>> ARIN, at its sole discretion, may waive this requirement if the >>> requester can document an unforeseen change in circumstances since their >>> last request?. >>> >>> As written, the portion of the policy that starts with ?but ARIN, at its >>> sole discretion? gives no concrete criteria for staff to use in its >>> assessment of the request. This ?exception clause? is open to >>> interpretation and may not be applied consistently by staff if there are >>> no guidelines or rules for staff to follow. It essentially allows ARIN >>> staff to determine the policy criteria for who can or can?t qualify >>> under this waiver. >>> >>> B. ARIN General Counsel >>> >>> "At this time counsel has no significant legal comments. Any system to >>> order and prioritize requests for resources which may exceed the >>> available resources must permit consistent administration by ARIN." >>> >>> 3. Resource Impact >>> >>> This policy would have moderate resource impact. It is estimated that >>> implementation would occur within 6 months after ratification by the >>> ARIN Board of Trustees. The following would be needed in order to >>> implement: >>> >>> ? The development of software to monitor IPv4 returns, a ?waiting list? >>> that will include request size as well as minimum size acceptable, and a >>> system that will match/compare returns with the waiting list >>> ? Modifications to the management web application >>> ? Changes to current business processes >>> ? Updated guidelines >>> ? Staff training >>> >>> >>> >>> 4. Proposal Text: Waiting list for unmet IPv4 requests >>> >>> Replace 4.1.6 with: >>> 4.1.6. Aggregation >>> In order to preserve aggregation, ARIN attempts to issue blocks of >>> addresses on appropriate "CIDR-supported" bit boundaries. As long as >>> sufficient space is available, ARIN may reserve space to maximize >>> aggregation possibilities. ARIN will make each allocation and assignment >>> as a single continuous range of addresses. >>> Add new section 4.1.8: >>> >>> 4.1.8 Unmet requests >>> In the event that ARIN does not have a contiguous block of addresses of >>> sufficient size to fulfill a qualified request, ARIN will provide the >>> requesting organization with the option to either modify their request >>> and request a smaller size block, or be placed on a waiting list of >>> pre-qualified recipients. Repeated requests, in a manner that would >>> circumvent 4.1.6, are not allowed: an organization may only receive one >>> allocation, assignment, or transfer every 3 months, but ARIN, at its >>> sole discretion, may waive this requirement if the requester can >>> document an unforeseen change in circumstances since their last request. >>> Qualified requesters whose request cannot be immediately met will also >>> be advised of the availability of the transfer mechanism in section 8.3 >>> as an alternative mechanism to obtain IPv4 addresses. >>> >>> 4.1.8.1 Waiting list >>> The position of each qualified request on the waiting list will be >>> determined by the date it was approved. Each organization may have one >>> approved request on the waiting list at a time. >>> >>> 4.1.8.2 Fulfilling unmet needs >>> As address blocks become available for allocation, ARIN will fulfill >>> requests on a first-approved basis, subject to the size of each >>> available address block and a re-validation of the original request. >>> Requests will not be partially filled. Any requests met through a >>> transfer will be considered fulfilled and removed from the waiting list. >>> >>> >>> Rationale: >>> ARIN will soon be unable to meet all approved requests for IPv4 address >>> space. In the absence of a policy like this, it is unclear what ARIN >>> should do with subsequent requests. >>> This policy would allocate reclaimed address blocks (and the last of the >>> ARIN free pool) on a first-come-first-served basis, while preserving >>> aggregation to the degree possible. As the free pool shrinks, requests >>> larger than the largest block left would be placed on a waiting list, >>> while smaller requests would use up the rest of it, until all requests >>> have to go on the waiting list. As additional reclaimed addresses become >>> available, the requests that have been waiting the longest would be met >>> first. If a requester gets the addresses they need via transfer, then >>> they would be removed from the waiting list and would need to wait and >>> submit a new request for additional address space, either directly or >>> via transfer. >>> >>> >>> >>> >>> FAQ: >>> Q1: The effect of 2009-8, if implemented by the Board, is to allow >>> transfers to be up to a 12 month supply of resources and up to a 3 month >>> supply for resource from the ARIN free pool. Does that jive with your >>> intent for this policy? >>> A1: Correct. After we get to the last /8, you can request up to a >>> 3-month supply from the free pool, but only every 3 months unless you >>> can document an unforeseen change in circumstances since your last >>> request. However, if you get the space via transfer, you can get a block >>> big enough for 12 month's need, and if you end up using it up faster, >>> you can submit another request after 3 months. >>> Q2: If I were on the waiting list, and subsequently received a transfer >>> via 8.3, would I be removed from the waiting list? >>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >>> will be considered fulfilled and removed from the waiting list." >>> Q3: Would receipt of an M&A transfer remove you from the waiting >>> list, too? >>> A3: I think that depends on how the M&A is justified. If you acquire a >>> company that is already efficiently utilizing all its IP space, I don't >>> think that would count toward fulfilling an outstanding need that you >>> have a request on the waiting list for. However, if your justification >>> for keeping the space held by the acquired company is that you plan to >>> use it for new stuff, then that would meet an outstanding need, and a >>> request for that same need would be considered fulfilled and removed >>> from the waiting list. >>> Q4: What about Multiple Discrete Networks? >>> A4: Allocations and assignments to organizations using the Multiple >>> Discrete Networks policy must still be made as a single continuous range >>> of addresses. This preserves future aggregatability of the space, and >>> ensures fairness between MDN and ordinary requests. >>> >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From scottleibrand at gmail.com Thu Jan 28 19:01:27 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 Jan 2010 16:01:27 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <4B622521.5000204@umn.edu> References: <4B58AED5.4030705@arin.net> <4B6201B6.20604@ipinc.net> <4B6205A4.6000501@gmail.com> <4B622521.5000204@umn.edu> Message-ID: <4B622557.6060801@gmail.com> On 1/28/2010 4:00 PM, David Farmer wrote: > Scott Leibrand wrote: >> Good point. I wonder if that would be covered by the existing clause >> that "ARIN will fulfill requests on a first-approved basis, subject >> to the size of each available address block and a re-validation of >> the original request"? If contact fails, then I'd say that >> re-validation fails as well. >> >> Thoughts? > > That should take care of part of it but maybe there should be a limit > on the time someone who is one the waiting list has to respond, so > that the resources can get allocated to the next person on the list, > if they are not responding. I would want resource tied up too long > while ARIN is trying to contact someone and fails, some small number > of days something in the range of 2 to 5 business days would seem > reasonable to move on to the next guy. > > Also, I think a quarterly check with those on the waiting list would > be reasonable too. Basically an email asking do they want to remain > on the waiting list, if they don't respond within some time frame they > can be removed from the list. > > If they don't want to be bothered then they don't have to be on the > list do they. Those sound like excellent suggestions for ARIN's operational procedures if/when they implement this policy. :-) -Scott > >> I'll go ahead and add a FAQ on this as well. >> >> Thanks, >> Scott >> >> On 1/28/2010 1:29 PM, Ted Mittelstaedt wrote: >>> My only comment to the AC on this is I think that you need to give ARIN >>> the ability to pull a request off the waiting list if they can no >>> longer >>> reach the requester. If a request on the list languishes for years, >>> it may only be satisfied once the Internet has shifted from IPv4 to >>> IPv6 >>> and orgs are abandoning IPv4 is droves - and at that time if they >>> cannot >>> reach the requester, it seems that the request will then be in limbo. >>> >>> Ted >>> >>> Member Services wrote: >>>> Draft Policy 2010-1 >>>> Waiting List for Unmet IPv4 Requests >>>> >>>> On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting >>>> List >>>> for Unmet IPv4 Requests" as a draft policy for adoption discussion on >>>> the PPML and at the Public Policy Meeting in Toronto in April. >>>> >>>> The draft was developed by the AC from Policy Proposal "97. Waiting >>>> List >>>> for Unmet IPv4 Requests". Per the Policy Development Process the AC >>>> submitted text to ARIN for a staff and legal assessment prior to its >>>> selection as a draft policy. Below the draft policy is the ARIN staff >>>> and legal assessment, including the original proposal text. >>>> >>>> Draft Policy 2010-1 is below and can be found at: >>>> https://www.arin.net/policy/proposals/2010_1.html >>>> >>>> You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to >>>> the April Public Policy Meeting. Both the discussion on the list and >>>> at the meeting will be used by the ARIN Advisory Council to determine >>>> the community consensus for adopting this as policy. >>>> >>>> The ARIN Policy Development Process can be found at: >>>> https://www.arin.net/policy/pdp.html >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> Regards, >>>> >>>> Member Services >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> ## * ## >>>> >>>> >>>> Draft Policy 2010-1 >>>> Waiting List for Unmet IPv4 Requests >>>> >>>> Version/Date: 21 January 2010 >>>> >>>> Policy statement: >>>> Replace 4.1.6 with: >>>> >>>> 4.1.6. Aggregation >>>> >>>> In order to preserve aggregation, ARIN attempts to issue blocks of >>>> addresses on appropriate "CIDR-supported" bit boundaries. As long as >>>> sufficient space is available, ARIN may reserve space to maximize >>>> aggregation possibilities. ARIN will make each allocation and >>>> assignment >>>> as a single continuous range of addresses. >>>> >>>> Add new section 4.1.8: >>>> >>>> 4.1.8 Unmet requests >>>> >>>> In the event that ARIN does not have a contiguous block of >>>> addresses of >>>> sufficient size to fulfill a qualified request, ARIN will provide the >>>> requesting organization with the option to either modify their request >>>> and request a smaller size block, or be placed on a waiting list of >>>> pre-qualified recipients. Repeated requests, in a manner that would >>>> circumvent 4.1.6, are not allowed: an organization may only receive >>>> one >>>> allocation, assignment, or transfer every 3 months, but ARIN, at its >>>> sole discretion, may waive this requirement if the requester can >>>> document an unforeseen change in circumstances since their last >>>> request. >>>> Qualified requesters whose request cannot be immediately met will also >>>> be advised of the availability of the transfer mechanism in section >>>> 8.3 >>>> as an alternative mechanism to obtain IPv4 addresses. >>>> >>>> 4.1.8.1 Waiting list >>>> >>>> The position of each qualified request on the waiting list will be >>>> determined by the date it was approved. Each organization may have one >>>> approved request on the waiting list at a time. >>>> >>>> 4.1.8.2 Fulfilling unmet needs >>>> >>>> As address blocks become available for allocation, ARIN will fulfill >>>> requests on a first-approved basis, subject to the size of each >>>> available address block and a re-validation of the original request. >>>> Requests will not be partially filled. Any requests met through a >>>> transfer will be considered fulfilled and removed from the waiting >>>> list. >>>> >>>> 8. Rationale: >>>> >>>> ARIN will soon be unable to meet all approved requests for IPv4 >>>> address >>>> space. In the absence of a policy like this, it is unclear what ARIN >>>> should do with subsequent requests. >>>> >>>> This policy would allocate reclaimed address blocks (and the last >>>> of the >>>> ARIN free pool) on a first-come-first-served basis, while preserving >>>> aggregation to the degree possible. As the free pool shrinks, requests >>>> larger than the largest block left would be placed on a waiting list, >>>> while smaller requests would use up the rest of it, until all requests >>>> have to go on the waiting list. As additional reclaimed addresses >>>> become >>>> available, the requests that have been waiting the longest would be >>>> met >>>> first. If a requester gets the addresses they need via transfer, then >>>> they would be removed from the waiting list and would need to wait and >>>> submit a new request for additional address space, either directly or >>>> via transfer. >>>> >>>> FAQ: >>>> >>>> Q1: The effect of 2009-8, if implemented by the Board, is to allow >>>> transfers to be up to a 12 month supply of resources and up to a 3 >>>> month >>>> supply for resource from the ARIN free pool. Does that jive with your >>>> intent for this policy? >>>> >>>> A1: Correct. After we get to the last /8, you can request up to a >>>> 3-month supply from the free pool, but only every 3 months unless you >>>> can document an unforeseen change in circumstances since your last >>>> request. However, if you get the space via transfer, you can get a >>>> block >>>> big enough for 12 month's need, and if you end up using it up faster, >>>> you can submit another request after 3 months. >>>> >>>> Q2: If I were on the waiting list, and subsequently received a >>>> transfer >>>> via 8.3, would I be removed from the waiting list? >>>> >>>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >>>> will be considered fulfilled and removed from the waiting list." >>>> >>>> Q3: Would receipt of an M&A transfer remove you from the waiting >>>> list, too? >>>> >>>> A3: I think that depends on how the M&A is justified. If you acquire a >>>> company that is already efficiently utilizing all its IP space, I >>>> don't >>>> think that would count toward fulfilling an outstanding need that you >>>> have a request on the waiting list for. However, if your justification >>>> for keeping the space held by the acquired company is that you plan to >>>> use it for new stuff, then that would meet an outstanding need, and a >>>> request for that same need would be considered fulfilled and removed >>>> from the waiting list. >>>> >>>> Q4: What about Multiple Discrete Networks? >>>> >>>> A4: Allocations and assignments to organizations using the Multiple >>>> Discrete Networks policy must still be made as a single continuous >>>> range >>>> of addresses. This preserves future aggregatability of the space, and >>>> ensures fairness between MDN and ordinary requests. >>>> >>>> Timetable for implementation: Immediate. >>>> >>>> >>>> ##### >>>> >>>> >>>> STAFF ASSESSMENT >>>> >>>> Proposal: Waiting List for Unmet IPv4 Requests >>>> Proposal Version: Updated by AC and given to staff for assessment >>>> on 29 >>>> Dec 2009 >>>> >>>> Date of Assessment: 12 January 2010 >>>> >>>> 1. Proposal Summary (Staff Understanding) >>>> >>>> Staff understands that this proposal would create a waiting list for >>>> requestors whose IPv4 address needs cannot be fulfilled by ARIN at the >>>> time of the request approval. The proposal includes text to prevent >>>> requestors from gaming the policy's intent by forbidding requestors >>>> from >>>> making multiple requests of a small size and limiting the issuance of >>>> space to no more than once every 3 months. >>>> >>>> 2. Comments >>>> >>>> A. ARIN Staff Comments >>>> >>>> ? In section 4.1.8, the author says ?Repeated requests, in a manner >>>> that >>>> would circumvent 4.1.6, are not allowed: an organization may only >>>> receive one allocation, assignment, or transfer every 3 months, but >>>> ARIN, at its sole discretion, may waive this requirement if the >>>> requester can document an unforeseen change in circumstances since >>>> their >>>> last request?. >>>> >>>> As written, the portion of the policy that starts with ?but ARIN, >>>> at its >>>> sole discretion? gives no concrete criteria for staff to use in its >>>> assessment of the request. This ?exception clause? is open to >>>> interpretation and may not be applied consistently by staff if >>>> there are >>>> no guidelines or rules for staff to follow. It essentially allows ARIN >>>> staff to determine the policy criteria for who can or can?t qualify >>>> under this waiver. >>>> >>>> B. ARIN General Counsel >>>> >>>> "At this time counsel has no significant legal comments. Any system to >>>> order and prioritize requests for resources which may exceed the >>>> available resources must permit consistent administration by ARIN." >>>> >>>> 3. Resource Impact >>>> >>>> This policy would have moderate resource impact. It is estimated that >>>> implementation would occur within 6 months after ratification by the >>>> ARIN Board of Trustees. The following would be needed in order to >>>> implement: >>>> >>>> ? The development of software to monitor IPv4 returns, a ?waiting >>>> list? >>>> that will include request size as well as minimum size acceptable, >>>> and a >>>> system that will match/compare returns with the waiting list >>>> ? Modifications to the management web application >>>> ? Changes to current business processes >>>> ? Updated guidelines >>>> ? Staff training >>>> >>>> >>>> >>>> 4. Proposal Text: Waiting list for unmet IPv4 requests >>>> >>>> Replace 4.1.6 with: >>>> 4.1.6. Aggregation >>>> In order to preserve aggregation, ARIN attempts to issue blocks of >>>> addresses on appropriate "CIDR-supported" bit boundaries. As long as >>>> sufficient space is available, ARIN may reserve space to maximize >>>> aggregation possibilities. ARIN will make each allocation and >>>> assignment >>>> as a single continuous range of addresses. >>>> Add new section 4.1.8: >>>> >>>> 4.1.8 Unmet requests >>>> In the event that ARIN does not have a contiguous block of >>>> addresses of >>>> sufficient size to fulfill a qualified request, ARIN will provide the >>>> requesting organization with the option to either modify their request >>>> and request a smaller size block, or be placed on a waiting list of >>>> pre-qualified recipients. Repeated requests, in a manner that would >>>> circumvent 4.1.6, are not allowed: an organization may only receive >>>> one >>>> allocation, assignment, or transfer every 3 months, but ARIN, at its >>>> sole discretion, may waive this requirement if the requester can >>>> document an unforeseen change in circumstances since their last >>>> request. >>>> Qualified requesters whose request cannot be immediately met will also >>>> be advised of the availability of the transfer mechanism in section >>>> 8.3 >>>> as an alternative mechanism to obtain IPv4 addresses. >>>> >>>> 4.1.8.1 Waiting list >>>> The position of each qualified request on the waiting list will be >>>> determined by the date it was approved. Each organization may have one >>>> approved request on the waiting list at a time. >>>> >>>> 4.1.8.2 Fulfilling unmet needs >>>> As address blocks become available for allocation, ARIN will fulfill >>>> requests on a first-approved basis, subject to the size of each >>>> available address block and a re-validation of the original request. >>>> Requests will not be partially filled. Any requests met through a >>>> transfer will be considered fulfilled and removed from the waiting >>>> list. >>>> >>>> >>>> Rationale: >>>> ARIN will soon be unable to meet all approved requests for IPv4 >>>> address >>>> space. In the absence of a policy like this, it is unclear what ARIN >>>> should do with subsequent requests. >>>> This policy would allocate reclaimed address blocks (and the last >>>> of the >>>> ARIN free pool) on a first-come-first-served basis, while preserving >>>> aggregation to the degree possible. As the free pool shrinks, requests >>>> larger than the largest block left would be placed on a waiting list, >>>> while smaller requests would use up the rest of it, until all requests >>>> have to go on the waiting list. As additional reclaimed addresses >>>> become >>>> available, the requests that have been waiting the longest would be >>>> met >>>> first. If a requester gets the addresses they need via transfer, then >>>> they would be removed from the waiting list and would need to wait and >>>> submit a new request for additional address space, either directly or >>>> via transfer. >>>> >>>> >>>> >>>> >>>> FAQ: >>>> Q1: The effect of 2009-8, if implemented by the Board, is to allow >>>> transfers to be up to a 12 month supply of resources and up to a 3 >>>> month >>>> supply for resource from the ARIN free pool. Does that jive with your >>>> intent for this policy? >>>> A1: Correct. After we get to the last /8, you can request up to a >>>> 3-month supply from the free pool, but only every 3 months unless you >>>> can document an unforeseen change in circumstances since your last >>>> request. However, if you get the space via transfer, you can get a >>>> block >>>> big enough for 12 month's need, and if you end up using it up faster, >>>> you can submit another request after 3 months. >>>> Q2: If I were on the waiting list, and subsequently received a >>>> transfer >>>> via 8.3, would I be removed from the waiting list? >>>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer >>>> will be considered fulfilled and removed from the waiting list." >>>> Q3: Would receipt of an M&A transfer remove you from the waiting >>>> list, too? >>>> A3: I think that depends on how the M&A is justified. If you acquire a >>>> company that is already efficiently utilizing all its IP space, I >>>> don't >>>> think that would count toward fulfilling an outstanding need that you >>>> have a request on the waiting list for. However, if your justification >>>> for keeping the space held by the acquired company is that you plan to >>>> use it for new stuff, then that would meet an outstanding need, and a >>>> request for that same need would be considered fulfilled and removed >>>> from the waiting list. >>>> Q4: What about Multiple Discrete Networks? >>>> A4: Allocations and assignments to organizations using the Multiple >>>> Discrete Networks policy must still be made as a single continuous >>>> range >>>> of addresses. This preserves future aggregatability of the space, and >>>> ensures fairness between MDN and ordinary requests. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > From todd at kcix.net Thu Jan 28 17:49:48 2010 From: todd at kcix.net (todd at kcix.net) Date: Thu, 28 Jan 2010 17:49:48 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality Message-ID: <0e4bb9ce4f656d6c3bde2b12a9b10fc6@kcix.net> I also support this policy proposal as written. Todd Bysfield Kansas City Internet eXchange 6910 W. 83rd St. Suite 207 Overland Park, KS 66204 http://www.kcix.net AS40542 I do not feel the AC should abandon Policy Proposal 95: Customer Confidentiality. I formally petition to move the following text forward for discussion on the list and at the next Public Policy Meeting. I would appreciate it if anyone this policy applies to would support moving this proposal forward by posting statements in support of the petition to this list. 1. Policy Proposal Name: Customer Confidentiality 2. Proposal Originator: Aaron Wendel 3. Proposal Version: 2.0 4. Date: 10 June 2009 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: ISPs may choose to enter the customer's name along with the ISP's address and phone number in reassignments and reallocations in lieu of the customer's address and phone number. The customer's actual information must be provided to ARIN on request and will be held in the strictest confidence. 8. Rationale: Version 2.0 clarifies the need for the customer name to remain in the SWIP and RWHOIS information. Customer contact lists are one of the most proprietary and confidential pieces of information in any business. The requirements for ISPs to publish those lists via SWIP or RWHOIS runs contrary to good business practices and invites competitors and others to solicit both individuals and companies receiving reassignments and sub allocations from upstream providers. 9. Timetable for implementation: immediate Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 Kansas City, MO 64106 816-256-3031 _______________________________________________ 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 network at dimenoc.com Thu Jan 28 20:06:12 2010 From: network at dimenoc.com (network at dimenoc.com) Date: Thu, 28 Jan 2010 20:06:12 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality Message-ID: <4B623484.4050703@dimenoc.com> I support the petition the advance proposal 95. DimeNoc AS33182 DIMEN-6 From steve at ibctech.ca Thu Jan 28 20:13:20 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 20:13:20 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> Message-ID: <4B623630.20703@ibctech.ca> Joe Morgan wrote: > That is really not the point of this proposal. The point is that I > should not have to give up my entire customer list to my competitors. There's something wrong about that sentence. If an IP address that has been SWIP'ed to a specific site is performing blatant network scans against you, I want you to be able to know who it is. To me, trying to hide customer information like this is much like security through obscurity, imho. > If somebody is having problems with a company doing business under my > IP space then there is no reason why they cant contact my arin abuse > poc. They can. If there is no PoC associated with a SWIP and only an address/phone listed within the SWIP, most people who use WHOIS will already know to just let it fall through to get the proper contact: Attack from 208.70.107.134?: %whois 208.70.107.134 ...look up the block: %whois -a NET-208-70-107-128-1 > I would rather those go to me than to the customer that can just > ignore it. I already have problems with people sending complaints to > the wrong places and I never even get contacted with the abuse > complaint. That's not a whois/swip problem. That's a people problem. > I don't understand as arin can request the information why > does it need to be open to the public? Why impose cost/time/effort/stress on ARIN when there is no need to do so? Perhaps if it is looked at in another light... *you* are concerned about competitors finding out who your *clients* are. If you are really concerned this much that other sales people will try to steal your clients because of data presented in whois, perhaps you are being selfish, as your clients may *want* to be included in whois, as it may be another avenue of visibility for their brand/company/whatever to a potential brand new market for them for their product ;) I doubt it, as I believe that whois is used by ops trying to reach ops, but I digress. Either way, I concur with the AC's decision that this policy should be abandoned. Steve From bicknell at ufp.org Thu Jan 28 20:21:57 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Jan 2010 17:21:57 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B62098C.60606@arin.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: <20100129012157.GA76910@ussenterprise.ufp.org> I support the petition. In a message written on Thu, Jan 28, 2010 at 05:02:52PM -0500, Member Services wrote: > With the message below a petition has started regarding the ARIN > Advisory Council's decision to abandon Proposal 95: Customer > Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the > ARIN Advisory Council (AC) had decided to abandon the proposal. > > If successful, this petition will change Proposal 95 into a Draft Policy > which will be published for discussion and review by the community on > the PPML and at the Public Policy Meeting in April. If the petition > fails, the proposal will be closed. > > For this petition to be successful, it will need statements of support > from at least 10 different people from 10 different organizations. If > you wish to support this petition, post a statement of support to PPML > on this thread. Point of contact information is required, either to the > entire PPML or with a follow up post to petition at arin.net with full POC > information (name, organization, street address, email, phone). > > The duration of the petition is five business days; it will end on 4 > February 2010. ARIN staff will post the result of the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Member Services > American Registry for Internet Numbers (ARIN) > > ##### > > Aaron Wendel wrote: > >I do not feel the AC should abandon Policy Proposal 95: Customer > >Confidentiality. I formally petition to move the following text forward for > >discussion on the list and at the next Public Policy Meeting. I would > >appreciate it if anyone this policy applies to would support moving this > >proposal forward by posting statements in support of the petition to this > >list. > > > >1. Policy Proposal Name: Customer Confidentiality > > > >2. Proposal Originator: Aaron Wendel > > > >3. Proposal Version: 2.0 > > > >4. Date: 10 June 2009 > > > >5. Proposal type: new > > > >6. Policy term: permanent > > > >7. Policy statement: > > > >ISPs may choose to enter the customer's name along with the ISP's > >address and phone number in reassignments and reallocations in lieu of > >the customer's address and phone number. The customer's actual > >information must be provided to ARIN on request and will be held in the > >strictest confidence. > > > >8. Rationale: > > > >Version 2.0 clarifies the need for the customer name to remain in the > >SWIP and RWHOIS information. > > > >Customer contact lists are one of the most proprietary and confidential > >pieces of information in any business. The requirements for ISPs to > >publish those lists via SWIP or RWHOIS runs contrary to good business > >practices and invites competitors and others to solicit both individuals > >and companies receiving reassignments and sub allocations from upstream > >providers. > > > >9. Timetable for implementation: immediate > > > >Aaron Wendel > >Wholesale Internet, Inc. > >324 E. 11th St. Suite 1000 > >Kansas City, MO 64106 > >816-256-3031 > > > >_______________________________________________ > >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. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From gbonser at seven.com Thu Jan 28 20:31:38 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 17:31:38 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B623630.20703@ibctech.ca> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> > > There's something wrong about that sentence. If an IP address that has > been SWIP'ed to a specific site is performing blatant network scans > against you, I want you to be able to know who it is. > > To me, trying to hide customer information like this is much like > security through obscurity, imho. There is another issue as well. Say someone has a misconfigured server, going through their transit provider to get them to fix it seems ridiculous. If one of your customers is engaging in malicious activity, I want to know not only who it is, but what other blocks do they have so I can keep an eye on those source addresses, too. And when they move to a different provider, I want to know that, too. If a customer has an AS and uses BGP, who their upstream connectivity comes from can be obtained without whois. Any major network on the planet has the BGP routing table. So are you asking that ASN information be private, too? The license plate on my car doesn't have my landlord's number on it. It has my number on it. And if I move to a different place, it still has my license number on it and not my new landlords. And if someone has a problem with what I am doing, they don't go to my landlord to get it sorted out. George From gbonser at seven.com Thu Jan 28 20:46:51 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 17:46:51 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> And a couple of other things: Is it a primary purpose of ARIN to protect the commercial interests of transit providers? If this is adopted, who are the categories of members who benefit and who are the categories of users who lose some capability, time savings, etc. ? Would such a rule enhance in any way the operations of end users, educational institutions, government entities, etc. ? Does the adoption of this rule favor one class of member over another? I have not made up my mind on the proposal. From joe at joesdatacenter.com Thu Jan 28 20:54:47 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Thu, 28 Jan 2010 19:54:47 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> Message-ID: <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> I don't understand why its ridiculous that I be contacted. If I have a customer abusing my TOS than I should know about it. I can only assume if a customer has a compromised box or is doing malicious activity on purpose that they are either going to keep doing it out of ignorance or are going to keep doing it for other malicious reasons. The license plate analogy also does not make any sense to me does your landlord own the car? If I hit your car parked on the side of the road should I contact you the owner or a buddy you had borrow the car? Does your landlord put every renter on the title? At the end of the day the proposal is about keeping my customer list private from other competitors and the proposal does not say I have to hide this information for all customers only that I have a choice to keep some information private. If a customer of mine has a asn and there own bgp session then this is not really an issue at all because they would not be using my ip space. And yes there are ways to track down customers on my network via bgp feeds or even reverse dns but that is much more difficult than just having a list provided by arin. Also on the abuse argument at the end of the day the only person who has control of what customers are doing on my network is me. If I decide that a customer is malicious in nature I shut them off. But that really has nothing to do with this proposal. On Thu, Jan 28, 2010 at 7:31 PM, George Bonser wrote: >> >> There's something wrong about that sentence. If an IP address that has >> been SWIP'ed to a specific site is performing blatant network scans >> against you, I want you to be able to know who it is. >> >> To me, trying to hide customer information like this is much like >> security through obscurity, imho. > > > There is another issue as well. ?Say someone has a misconfigured server, > going through their transit provider to get them to fix it seems > ridiculous. > > If one of your customers is engaging in malicious activity, I want to > know not only who it is, but what other blocks do they have so I can > keep an eye on those source addresses, too. ?And when they move to a > different provider, I want to know that, too. > > If a customer has an AS and uses BGP, who their upstream connectivity > comes from can be obtained without whois. ?Any major network on the > planet has the BGP routing table. ?So are you asking that ASN > information be private, too? > > The license plate on my car doesn't have my landlord's number on it. ?It > has my number on it. ?And if I move to a different place, it still has > my license number on it and not my new landlords. ?And if someone has a > problem with what I am doing, they don't go to my landlord to get it > sorted out. > > George > > _______________________________________________ > 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. > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From steve at ibctech.ca Thu Jan 28 21:03:14 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 21:03:14 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> Message-ID: <4B6241E2.4060103@ibctech.ca> George Bonser wrote: > And a couple of other things: > > Is it a primary purpose of ARIN to protect the commercial interests of > transit providers? I feel it prudent that all entities, commercial or not, have information available to be found if they are using N size of address block. Otherwise, I can 'hide' a client behind me, and then shift them to a friend who can also 'hide' them when abuse complaints come in, and effectively, pass around a potentially lucrative abuser, and the true good folk of the Internet community have no method to find out who the problem actually is. I like the idea of knowing who is using the IP, when a client needs to be assigned a block of them. Steve From gbonser at seven.com Thu Jan 28 21:14:02 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 18:14:02 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7490@RWC-EX1.corp.seven.com> > -----Original Message----- > From: joe at moccp.com [mailto:joe at moccp.com] On Behalf Of Joe Morgan > Sent: Thursday, January 28, 2010 5:55 PM > To: George Bonser > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > I don't understand why its ridiculous that I be contacted. Because there is no guarantee that because you SWIPed a network to someone that any of the traffic from that network is even going through you. An example from practical experience: Little dot-com gets SWIPed a /24 from you. Then they actually produce a product and decide they need to be multihomed. They also get a /24 from their new provider. Then they get even bigger and they move their production operations to their new colo facility that is owned by someone else. They decide to keep the /24 they have been using from you for their production facility which is also multihomed but that subnet is being announced only to the second and third provider. The second /24 they got from their second office provider is their office connectivity and being announced to you and the other office provider. So ... customer has a /24 of your space but not a single bit of that traffic is flowing through your network. That customer has not violated any ToS with your network. What are you going to do about it? But luckily I looked at the BGP route and discovered that the network doesn't flow through you and called them to pitch them on my great new network service for 10 cents a meg! What I am saying is that the ONLY benefit this proposal offers that I can tell is to protect the commercial interests of transit providers. Publishing of this data isn't a new thing that has suddenly harmed transit providers. It is the way the market has been forever. It is like an apartment manager demanding the phone company remove all his tenants' addresses from the phone book because the market is tight and he doesn't want a competing apartment complex calling them and offering them better deals. How does this proposal benefit me or the public at large? From gbonser at seven.com Thu Jan 28 21:22:28 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 18:22:28 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> In other words, the proposal only makes sense if a SWIPed network, in order to be anonymous, can not be multi-homed, can not announce the network to any other provider, and the ONLY transit path to the network must be through you. If the SWIPed network is multi-homed, then I would say under no circumstances can they remain private in the ARIN listing. And once you arrive there, what was the purpose of SWIPing them the network in the first place? And how do you enforce that rule? George From steve at ibctech.ca Thu Jan 28 21:27:00 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 21:27:00 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> Message-ID: <4B624774.4040303@ibctech.ca> George Bonser wrote: > In other words, the proposal only makes sense if a SWIPed network, in > order to be anonymous, can not be multi-homed, can not announce the > network to any other provider, and the ONLY transit path to the network > must be through you. > > > If the SWIPed network is multi-homed, then I would say under no > circumstances can they remain private in the ARIN listing. > > And once you arrive there, what was the purpose of SWIPing them the > network in the first place? And how do you enforce that rule? George, that is what I was just thinking after re-reading my last message. It's all well and fscking dandy for us who love to work in this industry, but in reality, there is no policing. Does it really matter? The only way policy will ever be completely adhered to is if we can free up ARIN resources from administration, and allow them more time to perform auditing functions. ...that wouldn't be a bad thing either, coming close to run-out time (imho). Steve From gbonser at seven.com Thu Jan 28 21:32:23 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 18:32:23 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca><5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com><38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7492@RWC-EX1.corp.seven.com> > > If the SWIPed network is multi-homed, then I would say under no > circumstances can they remain private in the ARIN listing. Let me amend that to: If the SWIPed network is multi-homed or single-homed to a DIFFERENT network that the one who SWIPed it, then under no circumstances can they remain private in the ARIN listing. From steve at ibctech.ca Thu Jan 28 21:42:11 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 21:42:11 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7492@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca><5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com><38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F7492@RWC-EX1.corp.seven.com> Message-ID: <4B624B03.2000901@ibctech.ca> George Bonser wrote: >> If the SWIPed network is multi-homed, then I would say under no >> circumstances can they remain private in the ARIN listing. > > Let me amend that to: > > If the SWIPed network is multi-homed or single-homed to a DIFFERENT > network that the one who SWIPed it, then under no circumstances can they > remain private in the ARIN listing. Operationally speaking, anything less than a /24 would be safe by operators who care about anything that has to do with this, as they won't be accepting advertisements smaller than this anyhow. This goes back to a theoretical question I asked before Christmas, whether I could just SWIP large blocks to myself if I was 'lazy'. I think what you are proposing leans too far into operations, and would put more burden on ARIN than required, when an op can just use the route tables to find the source themselves. If this policy does pass, I wouldn't want to see such extra stipulations added in... Steve From gbonser at seven.com Thu Jan 28 21:49:54 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 18:49:54 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B624774.4040303@ibctech.ca> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> <4B624774.4040303@ibctech.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7493@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Steve Bertrand > Sent: Thursday, January 28, 2010 6:27 PM > To: George Bonser > > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > George, that is what I was just thinking after re-reading my last > message. > > It's all well and fscking dandy for us who love to work in this > industry, but in reality, there is no policing. > > Does it really matter? The only way policy will ever be completely > adhered to is if we can free up ARIN resources from administration, and > allow them more time to perform auditing functions. > > ...that wouldn't be a bad thing either, coming close to run-out time > (imho). > > Steve > > And there is another issue. IP addresses aren't the property of the service provider. They are a community resource. People holding a community resource must be held accountable. If SWIP information is kept private, who is to know if someone has 10 /20 block from 10 different providers. Private SWIP info seems to me to be a way to get around run-out and quietly obtain more space from PA space than you can justify because you simply don't tell provider A about space you have from provider B. At this point in time, having anonymous SWIP is just a way for someone to scam the system and accumulate IP addresses before run-out. Because this proposal provides no benefit to the community at large, and because it has the potential to facilitate abuse of all sorts of other policy, I can't support this proposal. From gbonser at seven.com Thu Jan 28 21:51:42 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 18:51:42 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B624B03.2000901@ibctech.ca> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca><5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com><38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F7492@RWC-EX1.corp.seven.com> <4B624B03.2000901@ibctech.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7494@RWC-EX1.corp.seven.com> > > Operationally speaking, anything less than a /24 would be safe by > operators who care about anything that has to do with this, as they > won't be accepting advertisements smaller than this anyhow. Yes, I was thinking about blocks /24 or larger. From rudi.daniel at gmail.com Thu Jan 28 21:46:11 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 28 Jan 2010 22:46:11 -0400 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality Message-ID: <8aeeaff61001281846s3338b327w85baf0c1bbf27743@mail.gmail.com> I also support this policy proposal as written. RD -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at wholesaleinternet.net Thu Jan 28 21:02:33 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 28 Jan 2010 20:02:33 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> Message-ID: <03cc01caa087$1f1d3f40$5d57bdc0$@net> I believe ARIN should act to protect the interests of all its users. Right now, if I sell DSL, I can hide my customer information. If I manage a collocated server I can't. If this is adopted it will enable hosting providers to control access to their customer lists. Something every business is expected to do and as has been pointed out to me in the last hour, may be required to do under the Communications Privacy Act. One post stated that if people want to use a public network then they should post their info publically. I would say that a company like UPS uses public roads. Should they be required to disclose their customer lists to FedEx? If you are being scanned by a machine on my network I'm the first, and in most cases, the only one that needs to know about it and the only one that can do anything for you. Aaron -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of George Bonser Sent: Thursday, January 28, 2010 7:47 PM To: George Bonser; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality And a couple of other things: Is it a primary purpose of ARIN to protect the commercial interests of transit providers? If this is adopted, who are the categories of members who benefit and who are the categories of users who lose some capability, time savings, etc. ? Would such a rule enhance in any way the operations of end users, educational institutions, government entities, etc. ? Does the adoption of this rule favor one class of member over another? I have not made up my mind on the proposal. _______________________________________________ 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. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 13:36:00 From farmer at umn.edu Thu Jan 28 22:19:59 2010 From: farmer at umn.edu (David Farmer) Date: 28 Jan 2010 21:19:59 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <8aeeaff61001281846s3338b327w85baf0c1bbf27743@mail.gmail.com> References: <8aeeaff61001281846s3338b327w85baf0c1bbf27743@mail.gmail.com> Message-ID: Several people including Rudy below, have stated that they support the proposal as written, and that is all well and good. I would suggest that if in addition to supporting the text of the proposal you also support the Petition that is in process, that you should say that clearly too. I bring this up because it is not impossible for someone to think this proposal is a good idea, but to not support the Petition. As I am on the AC and already had my vote, so I take no position on the Petition either way, this Petition is for the rest of the community to decide. However, I would just like to make sure we avoid any misunderstandings in this whole process. Thanks On Jan 28 2010, Rudolph Daniel wrote: >I also support this policy proposal as written. > > >RD From steve at ibctech.ca Thu Jan 28 22:20:41 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 22:20:41 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <03cc01caa087$1f1d3f40$5d57bdc0$@net> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> <03cc01caa087$1f1d3f40$5d57bdc0$@net> Message-ID: <4B625409.3030803@ibctech.ca> Aaron Wendel wrote: > If you are being scanned by a machine on my network I'm the first, and in > most cases, the only one that needs to know about it and the only one that > can do anything for you. I don't think we're going to get anywhere with this policy, because my objectives have been solely focused on the fact that everyone will actually create proper SWIP records, and have the same mentality that I do, that the Internet runs based on the best interest of the community. With that said... I know how to look up your abuse PoC if the front-desk lady is the recipient of my phone call when I call the number listed in their SWIP. I will find you. So will anyone else troubleshooting a problem that requires digging up whois information. You, being a good netizen, having client SWIP info in the database, allows me to get the information of your client that is attacking me, and pass it along to a peer in the event that they see the same IP block attacking them via a different path. Or, if your malicious client signs up with an SP who also is a good community member, will list the same info in whois. Again, it's unlikely, as I'm slowly loosing faith that all ISPs are good ISPs :) Aside from knowing how to find you without you hiding information, did you consider what I said earlier about the potential advertisement stream for your clients that could be whois? Perhaps they may *want* to have their info listed. If you really feel that harvesters can find your clients that easily, perhaps your clients may believe that they can be found the same way for new revenue/market streams by potential clients of their own. Steve From todd at kcix.net Thu Jan 28 22:24:39 2010 From: todd at kcix.net (todd at kcix.net) Date: Thu, 28 Jan 2010 22:24:39 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: References: <8aeeaff61001281846s3338b327w85baf0c1bbf27743@mail.gmail.com> Message-ID: <9ffde89c9a62405db3c19301c03a0567@kcix.net> I support the petition as well as the proposal. :) Todd Bysfield Kansas City Internet eXchange 6910 W. 83rd St. Suite 207 Overland Park, KS 66204 http://www.kcix.net AS40542 On 28 Jan 2010 21:19:59 -0600, David Farmer wrote: > Several people including Rudy below, have stated that they support the > proposal as written, and that is all well and good. > > I would suggest that if in addition to supporting the text of the proposal > you also support the Petition that is in process, that you should say that > clearly too. I bring this up because it is not impossible for someone to > think this proposal is a good idea, but to not support the Petition. > > As I am on the AC and already had my vote, so I take no position on the > Petition either way, this Petition is for the rest of the community to > decide. > > However, I would just like to make sure we avoid any misunderstandings in > this whole process. > > Thanks > > On Jan 28 2010, Rudolph Daniel wrote: > >>I also support this policy proposal as written. >> >> >>RD > > _______________________________________________ > 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 gbonser at seven.com Thu Jan 28 22:29:55 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 19:29:55 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7493@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com><5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com><4B624774.4040303@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F7493@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7496@RWC-EX1.corp.seven.com> > Because this proposal provides no benefit to the community at large, > and > because it has the potential to facilitate abuse of all sorts of other > policy, I can't support this proposal. That said, I would not be opposed to a way to protect the service providers from someone perusing ARIN information for sales contacts. I just haven't come up with a good suggestion. Heck, it seems any time I update anything at ARIN, I get a new blast of sales calls. It is annoying, I know the sales drones do use ARINs information for sales contacts. You can't allow large providers unfettered access because they are one of the abusers of the current system. A provider filling a customer request for a block of addresses should have access to information on all blocks SWIPed to that customer. An end user attempting to track down abuse or troubleshooting a problem should be able to determine who owns a block and what other blocks they own. The idea should not be to shield an organization from having their network assignments known, but to shield the provider from having their network space crawled to determine who their customers are. George From aaron at wholesaleinternet.net Thu Jan 28 22:30:37 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 28 Jan 2010 21:30:37 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B625409.3030803@ibctech.ca> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> <03cc01caa087$1f1d3f40$5d57bdc0$@net> <4B625409.3030803@ibctech.ca> Message-ID: <03e401caa093$6cacefb0$4606cf10$@net> The proposal doesn't restrict information an ISP may disclose. Simply leaves it up to the ISP to decide with their customers and gives them the same options and protection that access providers (cable companies, DSL providers and Dial-up operators) currently enjoy. Aaron -----Original Message----- From: Steve Bertrand [mailto:steve at ibctech.ca] Sent: Thursday, January 28, 2010 9:21 PM To: Aaron Wendel Cc: 'George Bonser'; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality Aaron Wendel wrote: > If you are being scanned by a machine on my network I'm the first, and in > most cases, the only one that needs to know about it and the only one that > can do anything for you. I don't think we're going to get anywhere with this policy, because my objectives have been solely focused on the fact that everyone will actually create proper SWIP records, and have the same mentality that I do, that the Internet runs based on the best interest of the community. With that said... I know how to look up your abuse PoC if the front-desk lady is the recipient of my phone call when I call the number listed in their SWIP. I will find you. So will anyone else troubleshooting a problem that requires digging up whois information. You, being a good netizen, having client SWIP info in the database, allows me to get the information of your client that is attacking me, and pass it along to a peer in the event that they see the same IP block attacking them via a different path. Or, if your malicious client signs up with an SP who also is a good community member, will list the same info in whois. Again, it's unlikely, as I'm slowly loosing faith that all ISPs are good ISPs :) Aside from knowing how to find you without you hiding information, did you consider what I said earlier about the potential advertisement stream for your clients that could be whois? Perhaps they may *want* to have their info listed. If you really feel that harvesters can find your clients that easily, perhaps your clients may believe that they can be found the same way for new revenue/market streams by potential clients of their own. Steve No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 13:36:00 From steve at ibctech.ca Thu Jan 28 22:38:00 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 22:38:00 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <03e401caa093$6cacefb0$4606cf10$@net> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> <03cc01caa087$1f1d3f40$5d57bdc0$@net> <4B625409.3030803@ibctech.ca> <03e401caa093$6cacefb0$4606cf10$@net> Message-ID: <4B625818.4050303@ibctech.ca> Aaron Wendel wrote: > The proposal doesn't restrict information an ISP may disclose. Simply > leaves it up to the ISP to decide with their customers and gives them the > same options and protection that access providers (cable companies, DSL > providers and Dial-up operators) currently enjoy. ...reading this paragraph, you are trying to level a playing field of sorts... I thought that "cable companies, DSL providers and Dial-up operators" were ISPs... My understanding is if an 'ISP' doles out a /29, we have to SWIP it, and so would anyone else who has IP space allocated by ARIN, no matter what type of access they provide. What am I missing, and what are they enjoying that I'm not? I don't SWIP the IPs of my dial up clients, nor my DSL users when they don't have < /29. Steve From gbonser at seven.com Thu Jan 28 22:53:47 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 19:53:47 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <03e401caa093$6cacefb0$4606cf10$@net> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com><03cc01caa087$1f1d3f40$5d57bdc0$@net> <4B625409.3030803@ibctech.ca> <03e401caa093$6cacefb0$4606cf10$@net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7497@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Aaron Wendel > Sent: Thursday, January 28, 2010 7:31 PM > To: 'Steve Bertrand' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > The proposal doesn't restrict information an ISP may disclose. Simply > leaves it up to the ISP to decide with their customers and gives them > the > same options and protection that access providers (cable companies, DSL > providers and Dial-up operators) currently enjoy. > > Aaron But again, just because you SWIPed a network doesn't mean you have any control whatsoever on the traffic from that network. It might be in use on a different continent and not a bit of the traffic going through your network. What is calling you going to accomplish? And what prevents me from coming to you to get a /20 block if you can't verify what addresses I have assigned? How can you verify HD requirements? And then what prevents me from asking for a /20 block from both of my providers just so I have some "reserve" IP space after runout? If you can't see each other's SWIP information, what prevents abuse? This is absolutely the wrong time to do this. How about we do this; we say that under no circumstances will v4 SWIP info remain private because we are so close to run-out. The resource is too scarce to hide who has what and figure out a workable way to do this for v6. George From spamfree at wansecurity.com Thu Jan 28 23:06:24 2010 From: spamfree at wansecurity.com (Robert Smith) Date: Fri, 29 Jan 2010 13:06:24 +0900 Subject: [arin-ppml] I Support the petition to advance proposal 95 Message-ID: I Support the petition to advance proposal 95 -- -- Robert Smith, CISSP Director of Information Technology WANSecurity, Inc. From steve at ibctech.ca Thu Jan 28 23:13:41 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 23:13:41 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <1752205281-1264738071-cardhu_decombobulator_blackberry.rim.net-1894784826-@bda075.bisx.prod.on.blackberry> References: <1752205281-1264738071-cardhu_decombobulator_blackberry.rim.net-1894784826-@bda075.bisx.prod.on.blackberry> Message-ID: <4B626075.6020603@ibctech.ca> aaron at wholesaleinternet.net wrote: > You are missing section 4.2.3.7.6 Residential Customer Privacy of the policy manual giving ISP's the option to hide their residential customers. No, I did not miss section 4.2.3.7.6. It is overridden by 4.2.3.7.2, from what I can tell. Unfortunately, the word "previously" in that paragraph makes me think that there may be a loophole here... Steve From John.Kuhn at ontario.ca Thu Jan 28 23:15:39 2010 From: John.Kuhn at ontario.ca (Kuhn, John (MGS)) Date: Thu, 28 Jan 2010 23:15:39 -0500 Subject: [arin-ppml] (no subject) Message-ID: I Support the petition to advance proposal 95 John kuhn Government of ontario -------------------------- Sent from my BlackBerry Wireless Handheld From aaron at wholesaleinternet.net Thu Jan 28 23:19:19 2010 From: aaron at wholesaleinternet.net (aaron at wholesaleinternet.net) Date: Fri, 29 Jan 2010 04:19:19 +0000 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality Message-ID: <1752205281-1264738071-cardhu_decombobulator_blackberry.rim.net-1894784826-@bda075.bisx.prod.on.blackberry> You are missing section 4.2.3.7.6 Residential Customer Privacy of the policy manual giving ISP's the option to hide their residential customers. ------Original Message------ From: Steve Bertrand To: Aaron Wendel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality Sent: Jan 28, 2010 9:38 PM Aaron Wendel wrote: > The proposal doesn't restrict information an ISP may disclose. Simply > leaves it up to the ISP to decide with their customers and gives them the > same options and protection that access providers (cable companies, DSL > providers and Dial-up operators) currently enjoy. ...reading this paragraph, you are trying to level a playing field of sorts... I thought that "cable companies, DSL providers and Dial-up operators" were ISPs... My understanding is if an 'ISP' doles out a /29, we have to SWIP it, and so would anyone else who has IP space allocated by ARIN, no matter what type of access they provide. What am I missing, and what are they enjoying that I'm not? I don't SWIP the IPs of my dial up clients, nor my DSL users when they don't have < /29. Steve Sent from my Verizon Wireless BlackBerry From steve at ibctech.ca Thu Jan 28 23:20:55 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 28 Jan 2010 23:20:55 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: <36A8218C-21B0-4B5A-A0C7-0058A32FAD31@eyeconomics.com> References: <29756CA699484850BE8780CE3CC1F846@johnsonvhjjf8v> <36A8218C-21B0-4B5A-A0C7-0058A32FAD31@eyeconomics.com> Message-ID: <4B626227.4030000@ibctech.ca> tvest at eyeconomics.com wrote: > Hi Warren, > > Other, perhaps more practical ways of looking at it: > > The default public/open availability of comprehensive whois information > for the institutions controlling number resources represents a kind of > distributed mechanism for whois data error detection and correction. > Assuming that the practical needs that justify the creation and > maintenance of a comprehensive registration/whois service also justify > the maintenance of *accurate* (and complete, and timely) > registration/whois information, and consequently that the only > alternative to satisfying that need via a distributed feedback mechanism > is a mechanism that delivers/preserves the same accuracy levels through > purely internal (RIR staff administered) efforts, then the arrangement > with many eyes contributing is likely to be much more cost effective, > i.e., to provide the same benefits at a much lower cost to ARIN members. > > One might also consider the merits of this "distributed management" > approach to maintaining whois as a useful mechanism for preserving the > openness and transparency of ARIN policy outcomes. The more that such > (by current convention, "public") contact information remains publicly > accessible, the less ARIN members have to rely on ARIN staff to produce > summary answers to sensitive policy questions using > non-sharable/non-disclosable member data. In a world where virtually > every important institution is at the center of a permanent debate > between defenders of "x is generally good" and partisans of "x is > hopelessly corrupt" -- with the vast majority of stakeholders likely to > be in the "trust but verify" center -- seems like it would be prudent to > weigh the costs and benefits very carefully before eliminating the > public data resources that make such independent analysis/verification > efforts possible. ... ^ what he said. Steve From mysidia at gmail.com Thu Jan 28 23:57:45 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 28 Jan 2010 22:57:45 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7496@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <38dd4e411001281754r2089fde6u78324751d3f2927b@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F7491@RWC-EX1.corp.seven.com> <4B624774.4040303@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F7493@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F7496@RWC-EX1.corp.seven.com> Message-ID: <6eb799ab1001282057w7f4fda02va6fa9b47f21a6871@mail.gmail.com> On Thu, Jan 28, 2010 at 9:29 PM, George Bonser wrote: I am opposed to policy proposal 95. > That said, I would not be opposed to a way to protect the service > providers from someone perusing ARIN information for sales contacts. ?I > just haven't come up with a good suggestion. ?Heck, it seems any time I How about encouraging POCs to list unique contact information in the WHOIS directory (such as E-mail addresses and telephone numbers that are 'specific to the whois listing' and not used for any other purpose) and also: providing a dedicated ARIN e-mail address for reporting or forwarding WHOIS-related "marketing attempts" to? A public webpage gets dedicated to the purpose of listing any organizations responsible for spam complaints. If it gets too bad, or ARIN gets evidence the POC of an organization is complicit, revoke their IPs, or direct their ISP to do so, providing it can be proven they abused ARIN whois for the purpose of spamming contacts. I mean, the RSA signed by ISPs, End-Users, etc, ought to include a clause for address revokation in case of refusing to correct or cease certain abuses of ARIN resources on demand, such as using e-mail addresses or phone numbers collected from WHOIS to generate spam. Have a 'log' of what IPs requested what WHOIS records be kept. And perform correlation, so that the IP range that looked up the records that were 'abused' gets flagged as the spammer... -- -J From gbonser at seven.com Thu Jan 28 23:58:23 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Jan 2010 20:58:23 -0800 Subject: [arin-ppml] (no subject) In-Reply-To: <4B626227.4030000@ibctech.ca> References: <29756CA699484850BE8780CE3CC1F846@johnsonvhjjf8v><36A8218C-21B0-4B5A-A0C7-0058A32FAD31@eyeconomics.com> <4B626227.4030000@ibctech.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F749D@RWC-EX1.corp.seven.com> > > One might also consider the merits of this "distributed management" > > approach to maintaining whois as a useful mechanism for preserving > the > > openness and transparency of ARIN policy outcomes. The more that such > > (by current convention, "public") contact information remains > publicly > > accessible, the less ARIN members have to rely on ARIN staff to > produce > > summary answers to sensitive policy questions using > > non-sharable/non-disclosable member data. In a world where virtually > > every important institution is at the center of a permanent debate > > between defenders of "x is generally good" and partisans of "x is > > hopelessly corrupt" -- with the vast majority of stakeholders likely > to > > be in the "trust but verify" center -- seems like it would be prudent > to > > weigh the costs and benefits very carefully before eliminating the > > public data resources that make such independent > analysis/verification > > efforts possible. > > ... ^ what he said. More openness is better. If a provider knowingly provides incorrect info, they should be at risk of losing the IP space. The addresses do not belong to them, they are entrusted with them by the community. I am generally not in favor of things that stifle competition, either. I would possibly support a proposal that would eliminate SWIP/RWHOIS requirements for networks that are announced ONLY from the provider's network. SWIP would only be required if the network is announced out of another net or the address is to be disaggregated from the provider's block. That would probably remove a lot of the customers from the WHOIS information and serve most of the needs of the ISP. But I that might significantly increase the volume of calls and they might not have the staff to deal with that depending on how big they are. Putting a top end on the size of blocks not requiring SWIP might be a good idea ... maybe something like blocks ge /20 don't require SWIP if they have only one path to the Internet but then the provider themselves is held responsible for abuse if they don't SWIP it. If a customer were going to announce the network out of another ISP, I would think the ISP would WANT accurate SWIP data to be public so the customer could then be contacted directly if there were problems. For multi-homed networks using BGP and having an AS, one can find their customers anyway by looking up the ASNs announced from their networks space. For customers where the issuing provider is their sole transport path, the provider can then reasonably take actions to mitigate whatever the problem is so I don't have a problem with SWIP requirements being dropped completely for that case. From steve at ibctech.ca Fri Jan 29 00:09:22 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 29 Jan 2010 00:09:22 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F749D@RWC-EX1.corp.seven.com> References: <29756CA699484850BE8780CE3CC1F846@johnsonvhjjf8v><36A8218C-21B0-4B5A-A0C7-0058A32FAD31@eyeconomics.com> <4B626227.4030000@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F749D@RWC-EX1.corp.seven.com> Message-ID: <4B626D82.3020202@ibctech.ca> George Bonser wrote: >>> One might also consider the merits of this "distributed management" >>> approach to maintaining whois as a useful mechanism for preserving >> the >>> openness and transparency of ARIN policy outcomes. The more that > such >>> (by current convention, "public") contact information remains >> publicly >>> accessible, the less ARIN members have to rely on ARIN staff to >> produce >>> summary answers to sensitive policy questions using >>> non-sharable/non-disclosable member data. In a world where virtually >>> every important institution is at the center of a permanent debate >>> between defenders of "x is generally good" and partisans of "x is >>> hopelessly corrupt" -- with the vast majority of stakeholders > likely >> to >>> be in the "trust but verify" center -- seems like it would be > prudent >> to >>> weigh the costs and benefits very carefully before eliminating the >>> public data resources that make such independent >> analysis/verification >>> efforts possible. >> ... ^ what he said. > > More openness is better. If a provider knowingly provides incorrect > info, they should be at risk of losing the IP space. The addresses do > not belong to them, they are entrusted with them by the community. Yes. IIRC, the NRPM refers to the term 'license'. > I would possibly support a proposal that would eliminate SWIP/RWHOIS > requirements for networks that are announced ONLY from the provider's > network. I'm not in favour of this. It would cause undue overhead administratively, and would force someone (possibly ARIN) to validate this technically. If it's ge /29, it's SWIP'ed. Period. Steve From steve at ibctech.ca Fri Jan 29 00:26:13 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 29 Jan 2010 00:26:13 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: <4B626D82.3020202@ibctech.ca> References: <29756CA699484850BE8780CE3CC1F846@johnsonvhjjf8v><36A8218C-21B0-4B5A-A0C7-0058A32FAD31@eyeconomics.com> <4B626227.4030000@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F749D@RWC-EX1.corp.seven.com> <4B626D82.3020202@ibctech.ca> Message-ID: <4B627175.50009@ibctech.ca> Steve Bertrand wrote: > George Bonser wrote: >>>> One might also consider the merits of this "distributed management" >>>> approach to maintaining whois as a useful mechanism for preserving >>> the >>>> openness and transparency of ARIN policy outcomes. The more that >> such >>>> (by current convention, "public") contact information remains >>> publicly >>>> accessible, the less ARIN members have to rely on ARIN staff to >>> produce >>>> summary answers to sensitive policy questions using >>>> non-sharable/non-disclosable member data. In a world where virtually >>>> every important institution is at the center of a permanent debate >>>> between defenders of "x is generally good" and partisans of "x is >>>> hopelessly corrupt" -- with the vast majority of stakeholders >> likely >>> to >>>> be in the "trust but verify" center -- seems like it would be >> prudent >>> to >>>> weigh the costs and benefits very carefully before eliminating the >>>> public data resources that make such independent >>> analysis/verification >>>> efforts possible. >>> ... ^ what he said. >> More openness is better. If a provider knowingly provides incorrect >> info, they should be at risk of losing the IP space. The addresses do >> not belong to them, they are entrusted with them by the community. > > Yes. IIRC, the NRPM refers to the term 'license'. > >> I would possibly support a proposal that would eliminate SWIP/RWHOIS >> requirements for networks that are announced ONLY from the provider's >> network. > > I'm not in favour of this. It would cause undue overhead > administratively, and would force someone (possibly ARIN) to validate > this technically. > > If it's ge /29, it's SWIP'ed. Period. ...I'm glad I'm not writing prefix lists just now. I'm sure you know what was meant. Steve From owen at delong.com Fri Jan 29 01:12:25 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Jan 2010 22:12:25 -0800 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests In-Reply-To: <28E139F46D45AF49A31950F88C49745804FAA19B@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804FAA19B@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <6B297B2D-4DB6-4D38-A5A6-AD75596DC7BF@delong.com> On Jan 28, 2010, at 7:18 AM, wrote: >> The question here isn't about whether or not the requestor >> should accept crumbs, it's about whether the community is >> better served by giving all the remaining crumbs to a small >> number of large requestors, or, by giving some of the crumbs >> to a larger number of (potentially smaller) requestors. > > In the real world, talking about real crumbs, or at least food, > they give all the crumbs to a few strong members of the community > so that those members can apply their energy to getting more > food to save others from starvation. Of course not all communities > are so clever, and some of them ration out the crumbs, praying > for a miracle and then they all die together. > Depends on the cause of the food shortage. > I suggest that it is not ARIN's business to decide what better > serves the community, since ARIN is not lord and master of the > community, but its servant. ARIN should only try to be reasonably > fair, not make heroic efforts whose outcome could be worse, and > whose outcome is certainly unknowable. > ARIN is the community's steward over the address space and it is absolutely ARIN's role to balance the needs of the various stakeholders in the community and develop policies that meet the communities consensus of what best meets the community's need with the application of sound judgment by those elected by the community to that consensus. The idea of fair depends a great deal on perspective in the case in question. If you are the guy asking for a /14, then, fair is to give you all the pieces necessary for you to have address space equivalent to the /14. If your the guy who put in the request for a /24 30 seconds after the guy who asked for the /14, your idea of fair might be a bit different. >>> Definitely not. The option to get a /14 via transfer is >> something that >>> needs to be raised before an applicant submits their >> application. ARIN >>> needs to be clear about what blocks of what sizes, are on the shelf >>> waiting. >>> >> What's waiting on which shelf? ARIN will not have 100% >> visibility into the transfer availability. > > So what? ARINs job is to manage its own shelf, not commandeer everyone > else's. > ARIN can be somewhat clear about what is on ARIN's shelf, but, from your statement above, it was unclear about whether or not you expected ARIN to be clear about what was avilalble for transfer, thus my question. >> The ARIN shelf, >> OTOH, may well have rapidly varying contents such that a /14 >> was available when the person inquired, but, no longer >> available by the time ARIN received the application. > > That's life. When the cupboard is bare, it is bare. Finito la commedia. > It would be wrong of ARIN to publish the available IP address blocks > as any kind of a guarantee, but it is right to publish availability > information as a snapshot of what WAS AVAILABLE at the time the report > was produced, which may be a few hours out of date. No need to publish > more than daily data. > I agree, but, I also know that many web retailers I have worked with are loathe to publish information about whether a product is in stock before the customer has committed to the order because race conditions such as these make for very unhappy customers. >> What if the requestor thinks ARIN is likely to reclaim a >> large enough block and wants to wait for it? This policy >> allows the requestor to choose to sit in the queue in case >> such a block becomes available. > > What if pigs might learn to fly by growing silk ears. Requestors > might want to sit in the silk purse queue and wait for a flying > sow to appear over the horizon. > Let's stick to talking about IP addresses. To the best of my knowledge, ARIN is not involved in the stewardship of avian members of the porcine species or anything otherwise related to the silk trade. > Far better for them to get down to the rag market and haggle over > the price of an old silk dress that could be reworked into a silk > purse. > Who are you to decide which is better for them? Why should ARIN decide on their behalf? > In other words, if you look at the ARIN available blocks and it > seems that there is a significant risk that you will not get what > you need, then don't waste any more time with ARIN, and hunt > out in the wild for potential transfer blocks. > That's one strategy option. Not necessarily the only strategy. Clearly it's the one you think is best, but, like LDAP, it is not necessarily the best answer for everyone in every case. >> But some address space gets returned to or reclaimed by ARIN >> through various processes. Should we really turn the address >> distribution into a lottery based on timing your request to >> match the arrival of resources? That seems far worse to me. > > By that stage IPv4 address allocation is already a crap shoot > regardless of what ARIN does. It's like aid distribution in > disaster areas. The aid organizations try to do it in an orderly > way by giving tokens to mothers or every 10th person or whatever. > But once that person with the goods is out of view, who knows > what happens. In one case they were hoping to seed a market > by giving it to every 10th person, but they started a riot > instead. The lesson is that you cannot orchestrate human > behavior to the nth degree, not in Haiti and not in the IPv4 > address allocation arena. Back off and let nature take its > course, which in the case of ARIN is deployment of IPv6 > everywhere. We need more humility instead of thinking that we > can engineer solutions to every problem. Many problems are > beyond engineering, otherwise we would already be living in > a technocracy, not a democracy. > Last I looked, we lived in a representative republic and not a democracy. Even ARIN is run more like a representative republic than a democracy. Democracy doesn't scale. Nonetheless, I think that ARIN owes it to the community to consider all the views on what is the most fair process for distributing the last of the address space and any address space reclaimed thereafter. This proposal clearly differs from your view and your opposition is noted. However, other views are equally legitimate. >>> Then ARIN can censure the requester and block their IP >> addresses from >>> ARIN services. Meantime their competitors will be >> advertising to buy >>> reclaimable blocks and win the day. >>> >> Yeah, I think that the address application timing lottery >> that you are proposing is extremely poor stewardship, >> regardless of what set of rules you propose for preventing >> people from making frequent enough entries to attempt to >> guarantee a win. > > DoS attackers deserve what they get. > Thought exercise: Under your proposed method, where does one draw the line between DoS and legitimate efforts to have your request hit the lottery? How many lottery tickets should someone be allowed to request per what unit of time? > I gather you would rather see a system where people apply to > ARIN once, demonstrate their need once, and get their choice > of whatever addresses are on the shelf, > or a chit to be used when they find addresses in the market, > or a place in a waiting list for reclaimed addresses on the shelf, > or some combination of the three. > Yes. > Let's see, little ISP needs a /22 and applies to ARIN. They are > approved but there is only one /24 on the shelf. Little ISP > says, we'll take it, plus a chit for another /24, plus a place > in the queue for two more /24s. If they are unhappy with the > results of their market search, ARIN lets them exchange the > chit for another place in the queue, behind their original > queue postion for two /24s. > My intent would be to say that you can get any one of the above, not a combination... You can have the /24 on the shelf and make due with that, you can have a chit for the next /22 (or smaller) that is placed on the shelf, or, you can use your chit as proof of justification for a transfer of up to a /22. > That could work. How could it be done with a simple policy that > doesn't overmanage the situation? > I don't think policy has to be simple to be good. I think it is important for policy to be as simple as possible, but, I also think that attempts to make policy simpler than it needs to be cause greater problems. I am not a big fan of ignoring problems just because they seem too big or too complex. With thinking like that, we would not have an aerospace industry, we would never have visited the moon, and we will never make it to mars. Solving the difficult problems is what makes engineering interesting. Policy development is a combination of engineering and other disciplines in this case. I look forward to continuing to work on these difficult problems. Owen From owen at delong.com Fri Jan 29 02:29:31 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Jan 2010 23:29:31 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> Message-ID: Because it is not "your" IP space, it is the public IP space which you have been delegated stewardship over a portion of for so long as the you remain in compliance with the policies set by the community for your stewardship of that space. Being a public resource, those using anything more than a very small fraction of it should be publicly known and publicly accountable for their utilization of that public resource. Owen On Jan 28, 2010, at 3:04 PM, Joe Morgan wrote: > That is really not the point of this proposal. The point is that I > should not have to give up my entire customer list to my competitors. > If somebody is having problems with a company doing business under my > IP space then there is no reason why they cant contact my arin abuse > poc. I would rather those go to me than to the customer that can just > ignore it. I already have problems with people sending complaints to > the wrong places and I never even get contacted with the abuse > complaint. I don't understand as arin can request the information why > does it need to be open to the public? > > On Thu, Jan 28, 2010 at 4:42 PM, Scott Leibrand wrote: >> On 1/28/2010 2:35 PM, Ted Mittelstaedt wrote: >>> >>> Kevin Kargel wrote: >>>> >>>> I agree with and support the AC's decision to abandon Policy proposal 95. >>>> >>> >>> So do I, but I would suggest that anyone opposed DO NOT respond to >>> this. All your doing is re-opening the discussion again which is, >>> of course, exactly what the submitter wants. >> >> I voted to abandon this proposal, but IMO it's still perfectly valid to >> discuss the issue here on PPML. Specifically, the question at hand is >> whether to make this proposal a draft policy and discuss it at the >> face-to-face public policy meeting in Toronto. The AC gave our opinion, and >> now it's up to the community to petition to advance the proposal if enough >> of you disagree with the AC on the matter. >> >> This is also the first use of the petition process under the new PDP, so I'm >> hoping to see the process run smoothly, whatever the outcome. >> >> -Scott >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > Thank You, > Joe Morgan > Joe's Datacenter, LLC > http://joesdatacenter.com > _______________________________________________ > 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 joe at joesdatacenter.com Fri Jan 29 03:01:58 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Fri, 29 Jan 2010 02:01:58 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> Message-ID: <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> I am accountable for the utilization of the resources allocated to me by arin already. Saying that anyone utilizing a small fraction of it should be publicly known is a opinion not a fact. I'm only making this a point because this is a open discussion and I do not want people to mistake what you said as a factual statement when really its an opinion. I would also like to urge people to read the actual proposal because it states that I would still have to give the customers name but would only be hiding there address and telephone information which could easily be used by competitors to try and contact my customers. I have heard the debate about this proposal being used to try and hide malicious users but I would only have to assume that they could be dishonest about those customers to try and hide them even with the way it is handled now. That debate really has nothing to do with this proposal but more to do with consequences for people who do not handle abuse. The people who are honest about customer swip data would still provide the actual customer name and would only hide the address and phone number. If somebody wanted the malicious user removed from a network they would still contact the person who the ip space has been allocated too and who is ultimately responsible for it. I don't think anyone here is trying to claim that they own the ip space or that they want to harbor malicious users. On Fri, Jan 29, 2010 at 1:29 AM, Owen DeLong wrote: > Because it is not "your" IP space, it is the public IP space which you have > been delegated stewardship over a portion of for so long as the you remain > in compliance with the policies set by the community for your stewardship > of that space. > > Being a public resource, those using anything more than a very small fraction > of it should be publicly known and publicly accountable for their utilization > of that public resource. > > Owen > > On Jan 28, 2010, at 3:04 PM, Joe Morgan wrote: > >> That is really not the point of this proposal. The point is that I >> should not have to give up my entire customer list to my competitors. >> If somebody is having problems with a company doing business under my >> IP space then there is no reason why they cant contact my arin abuse >> poc. I would rather those go to me than to the customer that can just >> ignore it. I already have problems with people sending complaints to >> the wrong places and I never even get contacted with the abuse >> complaint. I don't understand as arin can request the information why >> does it need to be open to the public? >> >> On Thu, Jan 28, 2010 at 4:42 PM, Scott Leibrand wrote: >>> On 1/28/2010 2:35 PM, Ted Mittelstaedt wrote: >>>> >>>> Kevin Kargel wrote: >>>>> >>>>> I agree with and support the AC's decision to abandon Policy proposal 95. >>>>> >>>> >>>> So do I, but I would suggest that anyone opposed DO NOT respond to >>>> this. ?All your doing is re-opening the discussion again which is, >>>> of course, exactly what the submitter wants. >>> >>> I voted to abandon this proposal, but IMO it's still perfectly valid to >>> discuss the issue here on PPML. ?Specifically, the question at hand is >>> whether to make this proposal a draft policy and discuss it at the >>> face-to-face public policy meeting in Toronto. ?The AC gave our opinion, and >>> now it's up to the community to petition to advance the proposal if enough >>> of you disagree with the AC on the matter. >>> >>> This is also the first use of the petition process under the new PDP, so I'm >>> hoping to see the process run smoothly, whatever the outcome. >>> >>> -Scott >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> >> >> -- >> Thank You, >> Joe Morgan >> Joe's Datacenter, LLC >> http://joesdatacenter.com >> _______________________________________________ >> 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. > > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From owen at delong.com Fri Jan 29 03:12:30 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Jan 2010 00:12:30 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <03cc01caa087$1f1d3f40$5d57bdc0$@net> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> <03cc01caa087$1f1d3f40$5d57bdc0$@net> Message-ID: On Jan 28, 2010, at 6:02 PM, Aaron Wendel wrote: > I believe ARIN should act to protect the interests of all its users. Right > now, if I sell DSL, I can hide my customer information. If I manage a > collocated server I can't. > > If this is adopted it will enable hosting providers to control access to > their customer lists. Something every business is expected to do and as has > been pointed out to me in the last hour, may be required to do under the > Communications Privacy Act. > > One post stated that if people want to use a public network then they should > post their info publically. I would say that a company like UPS uses public > roads. Should they be required to disclose their customer lists to FedEx? > Different analogy... UPS and FedEx use public roads and are both required to have license plates and carrier license numbers which identify their vehicles to the public. This is about whether UPS and FedEx can use your highway with trucks that have a "Highway 101" paint-job and "US101" on every license plate, or, whether they have to put a "FedEx" or "UPS" paint job on the trucks and have unique license plates that can be identified. > If you are being scanned by a machine on my network I'm the first, and in > most cases, the only one that needs to know about it and the only one that > can do anything for you. > Then the machine shouldn't need a SWIP since it's in a /32 that you have administrative control over. SWIPs are only required for blocks that you assign to customers for machines that your customers administer. Owen > Aaron > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of George Bonser > Sent: Thursday, January 28, 2010 7:47 PM > To: George Bonser; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > And a couple of other things: > > Is it a primary purpose of ARIN to protect the commercial interests of > transit providers? > > If this is adopted, who are the categories of members who benefit and > who are the categories of users who lose some capability, time savings, > etc. ? > > Would such a rule enhance in any way the operations of end users, > educational institutions, government entities, etc. ? > > Does the adoption of this rule favor one class of member over another? > > I have not made up my mind on the proposal. > > _______________________________________________ > 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. > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 > 13:36:00 > > _______________________________________________ > 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 Fri Jan 29 03:18:25 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Jan 2010 00:18:25 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <03e401caa093$6cacefb0$4606cf10$@net> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> <03cc01caa087$1f1d3f40$5d57bdc0$@net> <4B625409.3030803@ibctech.ca> <03e401caa093$6cacefb0$4606cf10$@net> Message-ID: On Jan 28, 2010, at 7:30 PM, Aaron Wendel wrote: > The proposal doesn't restrict information an ISP may disclose. Simply > leaves it up to the ISP to decide with their customers and gives them the > same options and protection that access providers (cable companies, DSL > providers and Dial-up operators) currently enjoy. > Cable, DSL, and Dial-Up providers have the same restrictions you do. The policies are identical. You, too, can anonymize residential customer data in whois just like they can. In spite of the latest Supreme Court hallucination about corporate campaign spending, there really is a difference between business and residential customers. I'll remain neutral on the petition, but, I wanted to prevent any misunderstandings about the actual state of policy as the current policy does not provide the implied favoritism stated above. Owen > Aaron > > > -----Original Message----- > From: Steve Bertrand [mailto:steve at ibctech.ca] > Sent: Thursday, January 28, 2010 9:21 PM > To: Aaron Wendel > Cc: 'George Bonser'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > Aaron Wendel wrote: > >> If you are being scanned by a machine on my network I'm the first, and in >> most cases, the only one that needs to know about it and the only one that >> can do anything for you. > > I don't think we're going to get anywhere with this policy, because my > objectives have been solely focused on the fact that everyone will > actually create proper SWIP records, and have the same mentality that I > do, that the Internet runs based on the best interest of the community. > > With that said... > > I know how to look up your abuse PoC if the front-desk lady is the > recipient of my phone call when I call the number listed in their SWIP. > I will find you. So will anyone else troubleshooting a problem that > requires digging up whois information. > > You, being a good netizen, having client SWIP info in the database, > allows me to get the information of your client that is attacking me, > and pass it along to a peer in the event that they see the same IP block > attacking them via a different path. Or, if your malicious client signs > up with an SP who also is a good community member, will list the same > info in whois. > > Again, it's unlikely, as I'm slowly loosing faith that all ISPs are good > ISPs :) > > Aside from knowing how to find you without you hiding information, did > you consider what I said earlier about the potential advertisement > stream for your clients that could be whois? > > Perhaps they may *want* to have their info listed. If you really feel > that harvesters can find your clients that easily, perhaps your clients > may believe that they can be found the same way for new revenue/market > streams by potential clients of their own. > > Steve > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 > 13:36:00 > > _______________________________________________ > 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 joe at joesdatacenter.com Fri Jan 29 03:21:19 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Fri, 29 Jan 2010 02:21:19 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> <03cc01caa087$1f1d3f40$5d57bdc0$@net> Message-ID: <38dd4e411001290021o6e01ad39rebfc1a36968fcf0c@mail.gmail.com> I do not understand that analogy at all. What does that have to do with UPS or FEDEX providing a public list of all there customers because they use public roads. This proposal is not for arin members with ip allocations to be able to hide there information simply their customers. On Fri, Jan 29, 2010 at 2:12 AM, Owen DeLong wrote: > > On Jan 28, 2010, at 6:02 PM, Aaron Wendel wrote: > >> I believe ARIN should act to protect the interests of all its users. ?Right >> now, if I sell DSL, I can hide my customer information. ?If I manage a >> collocated server I can't. >> >> If this is adopted it will enable hosting providers to control access to >> their customer lists. ?Something every business is expected to do and as has >> been pointed out to me in the last hour, may be required to do under the >> Communications Privacy Act. >> >> One post stated that if people want to use a public network then they should >> post their info publically. ?I would say that a company like UPS uses public >> roads. ?Should they be required to disclose their customer lists to FedEx? >> > Different analogy... > > UPS and FedEx use public roads and are both required to have license > plates and carrier license numbers which identify their vehicles to the > public. This is about whether UPS and FedEx can use your highway > with trucks that have a "Highway 101" paint-job and "US101" on every > license plate, or, whether they have to put a "FedEx" or "UPS" paint > job on the trucks and have unique license plates that can be > identified. > >> If you are being scanned by a machine on my network I'm the first, and in >> most cases, the only one that needs to know about it and the only one that >> can do anything for you. >> > Then the machine shouldn't need a SWIP since it's in a /32 that you > have administrative control over. ?SWIPs are only required for > blocks that you assign to customers for machines that your customers > administer. > > Owen > >> Aaron >> >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of George Bonser >> Sent: Thursday, January 28, 2010 7:47 PM >> To: George Bonser; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality >> >> And a couple of other things: >> >> Is it a primary purpose of ARIN to protect the commercial interests of >> transit providers? >> >> If this is adopted, who are the categories of members who benefit and >> who are the categories of users who lose some capability, time savings, >> etc. ? >> >> Would such a rule enhance in any way the operations of end users, >> educational institutions, government entities, etc. ? >> >> Does the adoption of this rule favor one class of member over another? >> >> I have not made up my mind on the proposal. >> >> _______________________________________________ >> 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. >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 >> 13:36:00 >> >> _______________________________________________ >> 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. > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From steve at ibctech.ca Fri Jan 29 03:24:59 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 29 Jan 2010 03:24:59 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net><4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><4B623630.20703@ibctech.ca> <5A6D953473350C4B9995546AFE9939EE081F748E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F748F@RWC-EX1.corp.seven.com> <03cc01caa087$1f1d3f40$5d57bdc0$@net> <4B625409.3030803@ibctech.ca> <03e401caa093$6cacefb0$4606cf10$@net> Message-ID: <4B629B5B.6010608@ibctech.ca> Owen DeLong wrote: > On Jan 28, 2010, at 7:30 PM, Aaron Wendel wrote: > >> The proposal doesn't restrict information an ISP may disclose. Simply >> leaves it up to the ISP to decide with their customers and gives them the >> same options and protection that access providers (cable companies, DSL >> providers and Dial-up operators) currently enjoy. >> > Cable, DSL, and Dial-Up providers have the same restrictions you do. > The policies are identical. You, too, can anonymize residential customer > data in whois just like they can. > > In spite of the latest Supreme Court hallucination about corporate campaign > spending, there really is a difference between business and residential > customers. > > I'll remain neutral on the petition, but, I wanted to prevent any misunderstandings > about the actual state of policy as the current policy does not provide the > implied favoritism stated above. What I want to know is: Can a person still be 'hidden' as a resi if they have been 'delegated' a /29 or larger, by an entity that 'holds' IP address space that was either assigned or allocated by ARIN. Steve From gbonser at seven.com Fri Jan 29 03:37:13 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Jan 2010 00:37:13 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F749E@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Joe Morgan > Sent: Friday, January 29, 2010 12:02 AM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > abuse. The people who are honest about customer swip data would still > provide the actual customer name and would only hide the address and > phone number. If somebody wanted the malicious user removed from a > network they would still contact the person who the ip space has been > allocated too and who is ultimately responsible for it. I don't think > anyone here is trying to claim that they own the ip space or that they > want to harbor malicious users. I want enough information to call the end user directly or I want them to be able to call me and tell me that it looks like one of my servers is borked. This isn't about the organizations wanting anonymity. This does not offer the end user any benefit and adds only additional work for everyone involved for no benefit to anyone except those commercial transit providers who wish to hide their customer base. How do we know that this would even make much of a difference? I am not against commercial transit providers, in fact I am all for them. In fact, anything that enhances competition tends to spur innovation and reduce my costs. This doesn't seem like one of those things. The problem right now seems to be that anyone can determine what prefixes are in use in a given area and crawl whois to find delegations. There might be some kind of mechanism to get people the information they want but everything I think of would be a lot more work for ARIN if they were try to police who was abusing the system. One thing I thought of was something akin to a registration number that points to the POC. In order to get the POC, one would have to ask ARIN for it. That could be automated but some mechanism would have to be built to check for abuse. Maybe a user registration would be required to get access to that function and that user's access could be revoked if they abused it. The point being that unless a mechanism for providing that information for legitimate uses emerges, I am going to be against keeping the POC information a secret. Having only a company name does very little for me, particularly when the company HQ is in Korea or India and the network is in the US. And quite frankly, the fact that one ISP cold-calls another ISPs customers matters to me about as much as one cell phone provider cold calling customers of a competing provider or a company contacting people working for their competition and offering them a job or a gas war between two stations on a corner. It's business and yeah, I understand that people want every edge they can get but I believe the blanket secrecy of SWIPs is a draconian way of dealing with the problem. George From jcurran at arin.net Fri Jan 29 08:42:26 2010 From: jcurran at arin.net (John Curran) Date: Fri, 29 Jan 2010 08:42:26 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B62098C.60606@arin.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: ARIN Community - I am reposting this Petition Announcement under a distinct subject line as otherwise not all mailing list participants may recognize that this process is underway. This is neither a statement for or against the petition, and all statements of support posted under the original thread or this one will be counted in the total. /John John Curran President and CEO ARIN On Jan 28, 2010, at 5:02 PM, Member Services wrote: > With the message below a petition has started regarding the ARIN > Advisory Council's decision to abandon Proposal 95: Customer > Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the > ARIN Advisory Council (AC) had decided to abandon the proposal. > > If successful, this petition will change Proposal 95 into a Draft Policy > which will be published for discussion and review by the community on > the PPML and at the Public Policy Meeting in April. If the petition > fails, the proposal will be closed. > > For this petition to be successful, it will need statements of support > from at least 10 different people from 10 different organizations. If > you wish to support this petition, post a statement of support to PPML > on this thread. Point of contact information is required, either to the > entire PPML or with a follow up post to petition at arin.net with full POC > information (name, organization, street address, email, phone). > > The duration of the petition is five business days; it will end on 4 > February 2010. ARIN staff will post the result of the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Member Services > American Registry for Internet Numbers (ARIN) > > ##### > > Aaron Wendel wrote: >> I do not feel the AC should abandon Policy Proposal 95: Customer >> Confidentiality. I formally petition to move the following text forward for >> discussion on the list and at the next Public Policy Meeting. I would >> appreciate it if anyone this policy applies to would support moving this >> proposal forward by posting statements in support of the petition to this >> list. >> >> 1. Policy Proposal Name: Customer Confidentiality >> >> 2. Proposal Originator: Aaron Wendel >> >> 3. Proposal Version: 2.0 >> >> 4. Date: 10 June 2009 >> >> 5. Proposal type: new >> >> 6. Policy term: permanent >> >> 7. Policy statement: >> >> ISPs may choose to enter the customer's name along with the ISP's >> address and phone number in reassignments and reallocations in lieu of >> the customer's address and phone number. The customer's actual >> information must be provided to ARIN on request and will be held in the >> strictest confidence. >> >> 8. Rationale: >> >> Version 2.0 clarifies the need for the customer name to remain in the >> SWIP and RWHOIS information. >> >> Customer contact lists are one of the most proprietary and confidential >> pieces of information in any business. The requirements for ISPs to >> publish those lists via SWIP or RWHOIS runs contrary to good business >> practices and invites competitors and others to solicit both individuals >> and companies receiving reassignments and sub allocations from upstream >> providers. >> >> 9. Timetable for implementation: immediate >> >> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 >> Kansas City, MO 64106 >> 816-256-3031 >> >> _______________________________________________ >> 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 jim at tgasolutions.com Fri Jan 29 08:55:22 2010 From: jim at tgasolutions.com (Jim McBurnett) Date: Fri, 29 Jan 2010 08:55:22 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> Message-ID: Owen, Thanks for the reply.. I wish I had time and budget to go the meetings.. I have not seen anymore comments on this... Has an consensus been made? Thanks, Jim >>Thanks for your comments. >>I hope you will post more often and make your voice known at the public >>policy meeting, either in person, or, through remote participation. >>Owen From mysidia at gmail.com Fri Jan 29 09:36:16 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 29 Jan 2010 08:36:16 -0600 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> Message-ID: <6eb799ab1001290636p1731c36w2fef45e9431a50b5@mail.gmail.com> On Mon, Jan 25, 2010 at 2:32 PM, Jim McBurnett wrote: > As a consultant, I have several customers that are multi-homed. Many have the issue of getting > IP Space from an ISP. ?Some ISP's have to be read ARIN policy on the multi-home requirement > To allow for a /24.. Granted some of these customers cannot truly justify a /24 for that site. > HOWEVER-- there are concerns for them to do some other redundancy options.. To successfully multihome, with an AS number in the real world and achieve global reachability /24 is required. Even under the current NRPM, organizations who are going to multi-home, and can provide solid business justification why multi-homing is required, should be able to justify a /24 to their ISP or ARIN on that basis. That is: a network design that requires multihoming to achieve the required level of fault tolerance, and reachability during the failure of an upstream provider has a technical requirement for a /24 or shorter prefix. Since prefixes longer than /24 are usually not propagated by the major internet backbones. There you have a solid justification for a /24. The primary concern from a policy perspective to ARIN and to the ISP should be to prevent end-users from LYING and showing a network design that includes multi-homing, where in fact they have no real intention to multihome for the redundancy they claim they want. There is a risk the user could get their /24, and then cancel the service with their other provider. Or just never get the second link in place (if it was just "planned multihoming") --- I.E. the real reason they wanted the /24 was not to multihome, but to get IPs; since they got much more than they need, they'll never be coming back to ARIN to get denied a second allocation, e.g. they're "set for life". Or when they really have no solid technical basis for say multi-homing rather than getting redundant links from one well-connected multi-homed upstream ISP. If ARIN starts allocating /24s, it may need to find itself having to make more decisions like that, or allow more IP addresses to be allocated than would otherwise. Currently ARIN doesn't allocate those, so it needn't worry about it, only the ISP of the user who requests a /24 (currently) has to be concerned with "Does this user _really_ need to multihome for a good reason?" And charging them an appropriate price for that /24, given the opportunity cost of allocating that /24, and the limited remaining IPv4 space. -- -J From bicknell at ufp.org Fri Jan 29 09:48:11 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 Jan 2010 06:48:11 -0800 Subject: [arin-ppml] Customer Confidentially and IPv6 Message-ID: <20100129144811.GA47271@ussenterprise.ufp.org> Customer Confidentially seems to have degenerated into the same old same old in the various threads on it. As such I don't have much hope for us to come to a conclusion, since we haven't been able to before. However, I would like to point out there is something different going on now that was not happening in 2004 when the last discussion started; IPv6. We have this notion in IPv4 that /0-/28 need to be in the database, and /29-/32 are optional in the database. We also have a distinction that dynamic addresses need not be SWIP'ed, but static ones do. This is why those who assign a single dynamic IP (e.g. a cable modem) don't put their entire customer list in WHOIS, but those who assign a /28 (e.g. some DSL providers) do. There are several arguments about why this is, but they all come down to some form of "if you have more than x addresses you're using enough of the public commons that you should be listed". Well, what happens in IPv6? In the NRPM today, 6.5.4.4 states "All /56 and larger assignments to end sites are required to be registered". So for instance if the cable modem provider today who provides a single dynamic IP via DHCP and puts none of them in SWIP decides to provide every customer with a /48 (as many want them to do) or even a /56, via DHCP-PD they will be required to put those dynamic assignments into SWIP. So we are at a cross roads where we are poised either to add literally tens of millions of records to SWIP and cause a new dump of customer databases to ARIN; or perhaps we will inadvertently force many ISP's to hand out /60's and /64's to customers so they don't have to deal with putting these customers into WHOIS. I think either would be a disservice to the community. Given IPv4's end game is near I don't really care how SWIP gets applied to IPv4 anymore. It is what it is, and there is no reason to revisit the issue. However, IPv6 fundamentally alters some of the arguments used with respect to who is in the database and how they are listed. I think the AC would be wise to take this proposal and use it to foster a discussion of WHOIS in an IPv6 world. Privacy of residential customers has clearly been an ongoing concern in various policies, and if IPv6 lists whole classes of users that are not listed today then the level of concern will likely skyrocket. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dsd at carpathiahost.com Fri Jan 29 10:12:37 2010 From: dsd at carpathiahost.com (David Divins) Date: Fri, 29 Jan 2010 10:12:37 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: <0BA324910E97E54EBC94D0E358E63DB0196252D8@EX2K7VS02.4emm.local> I support the petition not to abandon and I support the proposal. It appears that everyone is purely looking at this from a transit perspective (where the addresses to or not be SWIPd are the source). Think of this from a content provider perspective (where the addresses are the destination). Not everyone wants to publish where there systems are (they may not use DNS or use private DNS). -dsd David S. Divins Principal Engineer Carpathia Hosting, Inc. 43480 Yukon Dr., #200 Ashburn, VA ?20147 (703) 652-5955 www.carpathiahost.com ServerVault is now Carpathia Hosting! www.carpathiahosting.com? This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Friday, January 29, 2010 8:42 AM To: arin-ppml at arin.net Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive ARIN Community - I am reposting this Petition Announcement under a distinct subject line as otherwise not all mailing list participants may recognize that this process is underway. This is neither a statement for or against the petition, and all statements of support posted under the original thread or this one will be counted in the total. /John John Curran President and CEO ARIN On Jan 28, 2010, at 5:02 PM, Member Services wrote: > With the message below a petition has started regarding the ARIN > Advisory Council's decision to abandon Proposal 95: Customer > Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the > ARIN Advisory Council (AC) had decided to abandon the proposal. > > If successful, this petition will change Proposal 95 into a Draft Policy > which will be published for discussion and review by the community on > the PPML and at the Public Policy Meeting in April. If the petition > fails, the proposal will be closed. > > For this petition to be successful, it will need statements of support > from at least 10 different people from 10 different organizations. If > you wish to support this petition, post a statement of support to PPML > on this thread. Point of contact information is required, either to the > entire PPML or with a follow up post to petition at arin.net with full POC > information (name, organization, street address, email, phone). > > The duration of the petition is five business days; it will end on 4 > February 2010. ARIN staff will post the result of the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Member Services > American Registry for Internet Numbers (ARIN) > > ##### > > Aaron Wendel wrote: >> I do not feel the AC should abandon Policy Proposal 95: Customer >> Confidentiality. I formally petition to move the following text forward for >> discussion on the list and at the next Public Policy Meeting. I would >> appreciate it if anyone this policy applies to would support moving this >> proposal forward by posting statements in support of the petition to this >> list. >> >> 1. Policy Proposal Name: Customer Confidentiality >> >> 2. Proposal Originator: Aaron Wendel >> >> 3. Proposal Version: 2.0 >> >> 4. Date: 10 June 2009 >> >> 5. Proposal type: new >> >> 6. Policy term: permanent >> >> 7. Policy statement: >> >> ISPs may choose to enter the customer's name along with the ISP's >> address and phone number in reassignments and reallocations in lieu of >> the customer's address and phone number. The customer's actual >> information must be provided to ARIN on request and will be held in the >> strictest confidence. >> >> 8. Rationale: >> >> Version 2.0 clarifies the need for the customer name to remain in the >> SWIP and RWHOIS information. >> >> Customer contact lists are one of the most proprietary and confidential >> pieces of information in any business. The requirements for ISPs to >> publish those lists via SWIP or RWHOIS runs contrary to good business >> practices and invites competitors and others to solicit both individuals >> and companies receiving reassignments and sub allocations from upstream >> providers. >> >> 9. Timetable for implementation: immediate >> >> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 >> Kansas City, MO 64106 >> 816-256-3031 >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bill at herrin.us Fri Jan 29 11:18:11 2010 From: bill at herrin.us (William Herrin) Date: Fri, 29 Jan 2010 11:18:11 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> Message-ID: <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> On Fri, Jan 29, 2010 at 8:55 AM, Jim McBurnett wrote: > Owen, > Thanks for the reply.. > I wish I had time and budget to go the meetings.. > > I have not seen anymore comments on this... Has an consensus been made? Jim, I'm waiting for the update to the text that Owen promised to close a hole in the language that could cause the renumbering and return of blocks much larger than /20. On Fri, Jan 29, 2010 at 9:36 AM, James Hess wrote: > The primary concern from a policy perspective to ARIN and to the ISP > should be to prevent end-users from LYING and showing a network > design that includes multi-homing, where in fact they have no real > intention to multihome for the redundancy they claim they want. Hi James, If you're willing to lie, it's not hard to justify a /22. That's fraud, however, so if you're found out you could be very suddenly without the IP addresses critical to your business. High risk for an insufficient reward. Operationally, it just hasn't been a problem. If it does become a problem, ARIN can trivially address it outside of the policy framework. They need only implement a SWIP-like framework in which each AS providing you with BGP service submits a template declaring their AS and your ORG. Right now, though, that would be a lot of work to implement a precaution that does not appear necessary. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Jan 29 11:36:04 2010 From: bill at herrin.us (William Herrin) Date: Fri, 29 Jan 2010 11:36:04 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> Message-ID: <3c3e3fca1001290836l1775d9c5ta0fbfba5d1231228@mail.gmail.com> On Fri, Jan 29, 2010 at 3:01 AM, Joe Morgan wrote: > I am accountable for the utilization of the resources allocated to me > by arin already. Saying that anyone utilizing a small fraction of it > should be publicly known is a opinion not a fact. Joe, It's my opinion that process TRANSPARENCY is critical to the operation of an NGO charged with maintaining a FINITE resource critical to the function of a multi-billion dollar industry. It's a fact that transparency requires reporting sufficient for members of the general public to audit process should they desire to do so. It's a fact that ISP address allocations are strictly dependent on downstream assignments. It's a fact that an audit can't positively confirm the accuracy of an end-user assignment without checking with the end-user. It's thus a conclusion resting solely on fact that transparency in the allocation process requires members of the general public to be able to contact the end-users to whom portions of the finite resource are assigned. So, the only opinion in the process is how transparent ARIN's operation should be. Once you decide that, the reporting requirements for downstream registries (= LIRs = ISPs) follows. The only way you get rid of this, as a matter of fact, is by unifying the allocation and assignment policies and moving to an assignment criteria that's not based on downstream assignment count for justification. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jim at tgasolutions.com Fri Jan 29 11:39:03 2010 From: jim at tgasolutions.com (Jim McBurnett) Date: Fri, 29 Jan 2010 11:39:03 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <6eb799ab1001290636p1731c36w2fef45e9431a50b5@mail.gmail.com> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> <6eb799ab1001290636p1731c36w2fef45e9431a50b5@mail.gmail.com> Message-ID: James, You are correct... BUT IIRC-- ARIN now requires copies of the ISP contracts... So that mitigates the issue of never Multihoming and getting IP space.. And the MH status is all the justification for a /24 by ARIN.. My statement should have read--- Without multihoming many of these users could not justify /24. Back when the /24 justification requirement was put into play, I was an advocate for this on this list.. Thanks! Jim -----Original Message----- From: James Hess [mailto:mysidia at gmail.com] Sent: Friday, January 29, 2010 9:36 AM To: Jim McBurnett Cc: Ted Mittelstaedt; arin ppml Subject: Re: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title On Mon, Jan 25, 2010 at 2:32 PM, Jim McBurnett wrote: > As a consultant, I have several customers that are multi-homed. Many have the issue of getting > IP Space from an ISP. ?Some ISP's have to be read ARIN policy on the multi-home requirement > To allow for a /24.. Granted some of these customers cannot truly justify a /24 for that site. > HOWEVER-- there are concerns for them to do some other redundancy options.. To successfully multihome, with an AS number in the real world and achieve global reachability /24 is required. Even under the current NRPM, organizations who are going to multi-home, and can provide solid business justification why multi-homing is required, should be able to justify a /24 to their ISP or ARIN on that basis. That is: a network design that requires multihoming to achieve the required level of fault tolerance, and reachability during the failure of an upstream provider has a technical requirement for a /24 or shorter prefix. Since prefixes longer than /24 are usually not propagated by the major internet backbones. There you have a solid justification for a /24. The primary concern from a policy perspective to ARIN and to the ISP should be to prevent end-users from LYING and showing a network design that includes multi-homing, where in fact they have no real intention to multihome for the redundancy they claim they want. There is a risk the user could get their /24, and then cancel the service with their other provider. Or just never get the second link in place (if it was just "planned multihoming") --- I.E. the real reason they wanted the /24 was not to multihome, but to get IPs; since they got much more than they need, they'll never be coming back to ARIN to get denied a second allocation, e.g. they're "set for life". Or when they really have no solid technical basis for say multi-homing rather than getting redundant links from one well-connected multi-homed upstream ISP. If ARIN starts allocating /24s, it may need to find itself having to make more decisions like that, or allow more IP addresses to be allocated than would otherwise. Currently ARIN doesn't allocate those, so it needn't worry about it, only the ISP of the user who requests a /24 (currently) has to be concerned with "Does this user _really_ need to multihome for a good reason?" And charging them an appropriate price for that /24, given the opportunity cost of allocating that /24, and the limited remaining IPv4 space. -- -J From jim at tgasolutions.com Fri Jan 29 11:41:06 2010 From: jim at tgasolutions.com (Jim McBurnett) Date: Fri, 29 Jan 2010 11:41:06 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> Message-ID: Thanks Bill.... Yes.. I agree with the holding off.. Also-- Could someone correct me where I stated in the last post IRT the ISP contract requirements as a Multihoming request verification from ARIN? I think that would help put James at ease.... Thanks! jim -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Friday, January 29, 2010 11:18 AM To: Owen DeLong; arin ppml Subject: Re: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title On Fri, Jan 29, 2010 at 8:55 AM, Jim McBurnett wrote: > Owen, > Thanks for the reply.. > I wish I had time and budget to go the meetings.. > > I have not seen anymore comments on this... Has an consensus been made? Jim, I'm waiting for the update to the text that Owen promised to close a hole in the language that could cause the renumbering and return of blocks much larger than /20. On Fri, Jan 29, 2010 at 9:36 AM, James Hess wrote: > The primary concern from a policy perspective to ARIN and to the ISP > should be to prevent end-users from LYING and showing a network > design that includes multi-homing, where in fact they have no real > intention to multihome for the redundancy they claim they want. Hi James, If you're willing to lie, it's not hard to justify a /22. That's fraud, however, so if you're found out you could be very suddenly without the IP addresses critical to your business. High risk for an insufficient reward. Operationally, it just hasn't been a problem. If it does become a problem, ARIN can trivially address it outside of the policy framework. They need only implement a SWIP-like framework in which each AS providing you with BGP service submits a template declaring their AS and your ORG. Right now, though, that would be a lot of work to implement a precaution that does not appear necessary. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ 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 marty at akamai.com Fri Jan 29 11:51:07 2010 From: marty at akamai.com (Martin Hannigan) Date: Fri, 29 Jan 2010 11:51:07 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B62098C.60606@arin.net> References: <4B62098C.60606@arin.net> Message-ID: <877FA9EB-C2AD-4EE6-99D9-4ACBDB4892FC@akamai.com> On Jan 28, 2010, at 5:02 PM, Member Services wrote: > With the message below a petition has started regarding the ARIN > Advisory Council's decision to abandon Proposal 95: Customer > Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the > ARIN Advisory Council (AC) had decided to abandon the proposal. > > I support the petition. -M< From thorsten.ziegler at 1and1.com Fri Jan 29 11:39:12 2010 From: thorsten.ziegler at 1and1.com (Thorsten Ziegler) Date: Fri, 29 Jan 2010 17:39:12 +0100 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <02c701caa054$b71df010$2559d030$@net> References: <02c701caa054$b71df010$2559d030$@net> Message-ID: <53E2CD30FF6030408E06D9E345DC18A109EAD89C@WEBEXCHANGE.webde.local> I do support the petition. 1&1 Internet, AS8560 Regards, Thorsten > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Aaron Wendel > Sent: Thursday, January 28, 2010 2:02 PM > To: ppml at arin.net > Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > I do not feel the AC should abandon Policy Proposal 95: > Customer Confidentiality. I formally petition to move the > following text forward for discussion on the list and at the > next Public Policy Meeting. I would appreciate it if anyone > this policy applies to would support moving this proposal > forward by posting statements in support of the petition to this list. > > 1. Policy Proposal Name: Customer Confidentiality > > 2. Proposal Originator: Aaron Wendel > > 3. Proposal Version: 2.0 > > 4. Date: 10 June 2009 > > 5. Proposal type: new > > 6. Policy term: permanent > > 7. Policy statement: > > ISPs may choose to enter the customer's name along with the > ISP's address and phone number in reassignments and > reallocations in lieu of the customer's address and phone > number. The customer's actual information must be provided > to ARIN on request and will be held in the strictest confidence. > > 8. Rationale: > > Version 2.0 clarifies the need for the customer name to > remain in the SWIP and RWHOIS information. > > Customer contact lists are one of the most proprietary and > confidential pieces of information in any business. The > requirements for ISPs to publish those lists via SWIP or > RWHOIS runs contrary to good business practices and invites > competitors and others to solicit both individuals and > companies receiving reassignments and sub allocations from > upstream providers. > > 9. Timetable for implementation: immediate > > Aaron Wendel > Wholesale Internet, Inc. > 324 E. 11th St. Suite 1000 > Kansas City, MO 64106 > 816-256-3031 > > _______________________________________________ > 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 Fri Jan 29 12:38:13 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 29 Jan 2010 11:38:13 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <0BA324910E97E54EBC94D0E358E63DB0196252D8@EX2K7VS02.4emm.local> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <0BA324910E97E54EBC94D0E358E63DB0196252D8@EX2K7VS02.4emm.local> Message-ID: <8695009A81378E48879980039EEDAD28876D3F80@MAIL1.polartel.local> > > I support the petition not to abandon and I support the proposal. > > It appears that everyone is purely looking at this from a transit > perspective (where the addresses to or not be SWIPd are the source). > Think of this from a content provider perspective (where the addresses are > the destination). Not everyone wants to publish where there systems are > (they may not use DNS or use private DNS). > > -dsd > Whether they want to or not is moot. If they are going to be using resources in the public arena and those resources have the possibility of causing problems then they need to be contactable. It is that simple. If they want to be completely anonymous and untraceable the solution is simple, stay off the internet. From mprice at tqhosting.com Fri Jan 29 12:39:45 2010 From: mprice at tqhosting.com (Mark Price) Date: Fri, 29 Jan 2010 12:39:45 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <53E2CD30FF6030408E06D9E345DC18A109EAD89C@WEBEXCHANGE.webde.local> References: <02c701caa054$b71df010$2559d030$@net> <53E2CD30FF6030408E06D9E345DC18A109EAD89C@WEBEXCHANGE.webde.local> Message-ID: <61b6fbec1001290939v6f197061u387357a465494671@mail.gmail.com> I strongly support the petition to advance proposal 95, Mark Price Tranquil Hosting, Inc. ARIN ORG ID: TRANQ AS13647 On Fri, Jan 29, 2010 at 11:39 AM, Thorsten Ziegler wrote: > I do support the petition. > > 1&1 Internet, AS8560 > > Regards, > ?Thorsten > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Aaron Wendel >> Sent: Thursday, January 28, 2010 2:02 PM >> To: ppml at arin.net >> Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality >> >> I do not feel the AC should abandon Policy Proposal 95: >> Customer Confidentiality. I formally petition to move the >> following text forward for discussion on the list and at the >> next Public Policy Meeting. I would appreciate it if anyone >> this policy applies to would support moving this proposal >> forward by posting statements in support of the petition to this list. >> >> 1. Policy Proposal Name: Customer Confidentiality >> >> 2. Proposal Originator: Aaron Wendel >> >> 3. Proposal Version: 2.0 >> >> 4. Date: 10 June 2009 >> >> 5. Proposal type: new >> >> 6. Policy term: permanent >> >> 7. Policy statement: >> >> ISPs may choose to enter the customer's name along with the >> ISP's address and phone number in reassignments and >> reallocations in lieu of the customer's address and phone >> number. ?The customer's actual information must be provided >> to ARIN on request and will be held in the strictest confidence. >> >> 8. Rationale: >> >> Version 2.0 clarifies the need for the customer name to >> remain in the SWIP and RWHOIS information. >> >> Customer contact lists are one of the most proprietary and >> confidential pieces of information in any business. ?The >> requirements for ISPs to publish those lists via SWIP or >> RWHOIS runs contrary to good business practices and invites >> competitors and others to solicit both individuals and >> companies receiving reassignments and sub allocations from >> upstream providers. >> >> 9. Timetable for implementation: immediate >> >> Aaron Wendel >> Wholesale Internet, Inc. >> 324 E. 11th St. ?Suite 1000 >> Kansas City, MO 64106 >> 816-256-3031 >> >> _______________________________________________ >> 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. > -- Mark Price Tranquil Hosting www.tqhosting.com office: 919-459-0134 From bill at herrin.us Fri Jan 29 13:25:56 2010 From: bill at herrin.us (William Herrin) Date: Fri, 29 Jan 2010 13:25:56 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B62098C.60606@arin.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> On Thu, Jan 28, 2010 at 5:02 PM, Member Services wrote: > With the message below a petition has started regarding the ARIN > Advisory Council's decision to abandon Proposal 95: Customer > Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the > ARIN Advisory Council (AC) had decided to abandon the proposal. > > If successful, this petition will change Proposal 95 into a Draft Policy > which will be published for discussion and review by the community on > the PPML and at the Public Policy Meeting in April. If the petition > fails, the proposal will be closed. I SUPPORT THE PETITION to move proposal 95 forward to a draft policy. The proposal is actionable and well formed and there is very obviously significant community interest. That a similar policy was defeated half a decade ago is insufficient cause to block this proposal's introduction and debate within the full policy community including ARIN meeting attendees. William Herrin AS 11875 3005 Crane Dr. Falls Church, VA 22042 That having been said, I oppose the policy proposal itself. Disclosure is critical to transparency in ARIN's process. Transparency is far more important than any corporate desire to avoid competition. Should the AC ultimately decide not to recommend it to the board on the grounds that it makes for bad policy, I will support that choice. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lar at mwtcorp.net Fri Jan 29 13:01:27 2010 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Fri, 29 Jan 2010 11:01:27 -0700 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F749E@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F749E@RWC-EX1.corp.seven.com> Message-ID: I support petition. > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On >> Behalf Of Joe Morgan >> Sent: Friday, January 29, 2010 12:02 AM >> To: Owen DeLong >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality >> >> abuse. The people who are honest about customer swip data would still >> provide the actual customer name and would only hide the address and >> phone number. If somebody wanted the malicious user removed from a >> network they would still contact the person who the ip space has been >> allocated too and who is ultimately responsible for it. I don't think >> anyone here is trying to claim that they own the ip space or that they >> want to harbor malicious users. > > I want enough information to call the end user directly or I want them > to be able to call me and tell me that it looks like one of my servers > is borked. This isn't about the organizations wanting anonymity. This > does not offer the end user any benefit and adds only additional work > for everyone involved for no benefit to anyone except those commercial > transit providers who wish to hide their customer base. How do we know > that this would even make much of a difference? No matter what you "want" I know for a fact that only two of the SWIP's I've filed has anyone on the other end that can even begin the understand what your talking about. More often than not we end up dispatching a tech to the customer location to help track down the offending machine if there's a problem. We file the SWIP anyway as required. We are talking about requiring disclosing information without the permission of the end user. (I know ARIN already has that policy and IMHO it's NUTS!) I have two /29's that I don't SWIP. The customer's have insisted on it (we hard mask their outbound telephone calls also) and they have a very good reason. The reason is obvious on it's face and it is unlikely to be a problem site. To do otherwise would be negligent at best, criminal at worst. All the "list lawyers" have ruled that the common good and necessity of disclosure outweighs the privacy concerns of the users. Does anyone know of a court that has made a ruling that supports that? I know that I used to be able to buy a vehicle plate to owner name cross reference book. It is my understanding that the a local court slapped it down. That is not public information. The police can request the owner of a plate they see only if they have some legitimate reason and are severly disciplined for requesting that information for any other reason. You State/Locale may differ. ARIN's policies need to have the flexibility to deal with the real world. The real world and the court systems don't really care much about ARIN policies nor the opinion of this list. Individual cases and reasonable judgment has to have a place. > I am not against commercial transit providers, in fact I am all for > them. In fact, anything that enhances competition tends to spur > innovation and reduce my costs. This doesn't seem like one of those > things. > Larry Ash ARIN ORG: CBS-129 Network Administrator Mountain West Telephone 400 East 1st St. Casper, WY 82601 Office 307 233-8387 From aaron at wholesaleinternet.net Fri Jan 29 13:44:37 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 29 Jan 2010 12:44:37 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F749C@RWC-EX1.corp.seven.com> References: <234506038-1264739765-cardhu_decombobulator_blackberry.rim.net-1497072405-@bda075.bisx.prod.on.blackberry> <5A6D953473350C4B9995546AFE9939EE081F749C@RWC-EX1.corp.seven.com> Message-ID: <04b401caa113$1c5c1dd0$55145970$@net> George, I don't think we're disagreeing per say. I think we're looking at this from different angles. There are a couple reasons I chose not to eliminate SWIPs in the proposal; One, it would never fly. Two, I have customers that want to be SWIP'd and are competent to field inquiries into their IP space and 3, I was looking for a simple proposal that would protect my customer list while still allowing others to see if a range was allocated, how much of it was allocated and to who it was allocated (by name). I felt that was a middle ground that everyone could live with. Plus ARIN still uses SWIP for justification. They don't care who it's assigned to, just that it's assigned. Nothing in my proposal takes away from anything that is already functional. It simply gives the ISP the ability, along with it's customer, to decide if the address, phone number and e-mail should be displayed. Name is still required. Aaron -----Original Message----- From: George Bonser [mailto:gbonser at seven.com] Sent: Thursday, January 28, 2010 10:45 PM To: aaron at wholesaleinternet.net Subject: RE: [arin-ppml] Policy Proposal 95: Customer Confidentiality > -----Original Message----- > From: aaron at wholesaleinternet.net [mailto:aaron at wholesaleinternet.net] > Sent: Thursday, January 28, 2010 8:48 PM > To: George Bonser > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > Yes. They require a SWIP or RWHOIS entry. It might benefit you to > read the requirements in the policy manual so you can make a more > informed opinion on the proposal. I would support a proposal that eliminates SWIP requirements for single-homed networks of any size provided the owning provider is the only announcement of that address space. If the network is to be announced from another provider or is multi-homed, I would say it must be public. Again, ARIN is not in the business of protecting providers from competition. But I do see a need to come up with some way to protect providers from having their lists raided. If this is a big problem for a company then they are probably charging more than the competition in that area and wants this in order to prevent loss of customers due to competition. And in order to provide this "protection" to the providers, we lose the ability to find out who is using address space that might not even be routed through the provider that SWIPed it. IP address assignments are a community resource, not a provider resource, and people holding those resources should be responsible to the community, not their provider. We can agree to disagree. How are you going to meet your HD requirements if you do this? How are you going to know your customer doesn't already have more than enough address space and is just getting some "insurance" from you for runout? George No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 13:36:00 From stephen.r.middleton at verizon.com Fri Jan 29 14:00:03 2010 From: stephen.r.middleton at verizon.com (Middleton, Stephen R) Date: Fri, 29 Jan 2010 14:00:03 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: Message-ID: I support the petition; contact information below. Thank you, Stephen Middleton Verizon Services Operations 1880 Campus Commons Dr Reston, VA 20191 IP Address Management IP and Data Backbone Engineering Stephen.r.middleton at verizon.com 703-390-0778 -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Friday, January 29, 2010 8:42 AM To: arin-ppml at arin.net Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive ARIN Community - I am reposting this Petition Announcement under a distinct subject line as otherwise not all mailing list participants may recognize that this process is underway. This is neither a statement for or against the petition, and all statements of support posted under the original thread or this one will be counted in the total. /John John Curran President and CEO ARIN On Jan 28, 2010, at 5:02 PM, Member Services wrote: > With the message below a petition has started regarding the ARIN > Advisory Council's decision to abandon Proposal 95: Customer > Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the > ARIN Advisory Council (AC) had decided to abandon the proposal. > > If successful, this petition will change Proposal 95 into a Draft Policy > which will be published for discussion and review by the community on > the PPML and at the Public Policy Meeting in April. If the petition > fails, the proposal will be closed. > > For this petition to be successful, it will need statements of support > from at least 10 different people from 10 different organizations. If > you wish to support this petition, post a statement of support to PPML > on this thread. Point of contact information is required, either to the > entire PPML or with a follow up post to petition at arin.net with full POC > information (name, organization, street address, email, phone). > > The duration of the petition is five business days; it will end on 4 > February 2010. ARIN staff will post the result of the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Member Services > American Registry for Internet Numbers (ARIN) > > ##### > > Aaron Wendel wrote: >> I do not feel the AC should abandon Policy Proposal 95: Customer >> Confidentiality. I formally petition to move the following text forward for >> discussion on the list and at the next Public Policy Meeting. I would >> appreciate it if anyone this policy applies to would support moving this >> proposal forward by posting statements in support of the petition to this >> list. >> >> 1. Policy Proposal Name: Customer Confidentiality >> >> 2. Proposal Originator: Aaron Wendel >> >> 3. Proposal Version: 2.0 >> >> 4. Date: 10 June 2009 >> >> 5. Proposal type: new >> >> 6. Policy term: permanent >> >> 7. Policy statement: >> >> ISPs may choose to enter the customer's name along with the ISP's >> address and phone number in reassignments and reallocations in lieu of >> the customer's address and phone number. The customer's actual >> information must be provided to ARIN on request and will be held in the >> strictest confidence. >> >> 8. Rationale: >> >> Version 2.0 clarifies the need for the customer name to remain in the >> SWIP and RWHOIS information. >> >> Customer contact lists are one of the most proprietary and confidential >> pieces of information in any business. The requirements for ISPs to >> publish those lists via SWIP or RWHOIS runs contrary to good business >> practices and invites competitors and others to solicit both individuals >> and companies receiving reassignments and sub allocations from upstream >> providers. >> >> 9. Timetable for implementation: immediate >> >> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 >> Kansas City, MO 64106 >> 816-256-3031 >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Jan 29 14:04:47 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Jan 2010 11:04:47 -0800 Subject: [arin-ppml] Customer Confidentially and IPv6 In-Reply-To: <20100129144811.GA47271@ussenterprise.ufp.org> References: <20100129144811.GA47271@ussenterprise.ufp.org> Message-ID: <0E328597-6576-4842-8EF8-6B3FED5EA1B9@delong.com> > > Well, what happens in IPv6? In the NRPM today, 6.5.4.4 states "All > /56 and larger assignments to end sites are required to be registered". > So for instance if the cable modem provider today who provides a > single dynamic IP via DHCP and puts none of them in SWIP decides > to provide every customer with a /48 (as many want them to do) or > even a /56, via DHCP-PD they will be required to put those dynamic > assignments into SWIP. > Actually, as I interpret the NRPM, they would be required to put the covering prefix of the DHCP pool into SWIP as a DHCP Pool, but, there is no need for the DHCP daemon to update SWIPS. If that isn't the case, you are correct that that area of policy needs work. However, for static persistent assignments of /56s or shorter prefixes to customers, I think it is perfectly reasonable to require SWIP just as we require it for /29 and shorter today. I do not see a need to expand customer anonymity beyond the current residential requirement. > So we are at a cross roads where we are poised either to add literally > tens of millions of records to SWIP and cause a new dump of customer > databases to ARIN; or perhaps we will inadvertently force many ISP's > to hand out /60's and /64's to customers so they don't have to deal > with putting these customers into WHOIS. I think either would be > a disservice to the community. > I'm uncertain why they couldn't use /57s even if what you say were true, but, again, I think that transient dynamic assignments are not subject to that requirement. > Given IPv4's end game is near I don't really care how SWIP gets > applied to IPv4 anymore. It is what it is, and there is no reason > to revisit the issue. However, IPv6 fundamentally alters some of > the arguments used with respect to who is in the database and how > they are listed. I think the AC would be wise to take this proposal > and use it to foster a discussion of WHOIS in an IPv6 world. Privacy > of residential customers has clearly been an ongoing concern in > various policies, and if IPv6 lists whole classes of users that are > not listed today then the level of concern will likely skyrocket. > I find it interesting that you expressed support for the petition in this case. As I understand it, the petition, if it succeeds will bring this IPv4-only proposal to the floor in Dearborn for adoption discussion. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From raul at datavo.com Fri Jan 29 14:03:30 2010 From: raul at datavo.com (Raul) Date: Fri, 29 Jan 2010 11:03:30 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B62098C.60606@arin.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: I support this petition. -Raul R. Network Administrator Datavo / AS26773 ARIN ORGID: DATAV-5 530 W. 6th St. Suite 300 Los Angeles, CA 90014 -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Thursday, January 28, 2010 2:03 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality With the message below a petition has started regarding the ARIN Advisory Council's decision to abandon Proposal 95: Customer Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the ARIN Advisory Council (AC) had decided to abandon the proposal. If successful, this petition will change Proposal 95 into a Draft Policy which will be published for discussion and review by the community on the PPML and at the Public Policy Meeting in April. If the petition fails, the proposal will be closed. For this petition to be successful, it will need statements of support from at least 10 different people from 10 different organizations. If you wish to support this petition, post a statement of support to PPML on this thread. Point of contact information is required, either to the entire PPML or with a follow up post to petition at arin.net with full POC information (name, organization, street address, email, phone). The duration of the petition is five business days; it will end on 4 February 2010. ARIN staff will post the result of the petition to PPML. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The proposal text is below and 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, Member Services American Registry for Internet Numbers (ARIN) ##### Aaron Wendel wrote: > I do not feel the AC should abandon Policy Proposal 95: Customer > Confidentiality. I formally petition to move the following text forward for > discussion on the list and at the next Public Policy Meeting. I would > appreciate it if anyone this policy applies to would support moving this > proposal forward by posting statements in support of the petition to this > list. > > 1. Policy Proposal Name: Customer Confidentiality > > 2. Proposal Originator: Aaron Wendel > > 3. Proposal Version: 2.0 > > 4. Date: 10 June 2009 > > 5. Proposal type: new > > 6. Policy term: permanent > > 7. Policy statement: > > ISPs may choose to enter the customer's name along with the ISP's > address and phone number in reassignments and reallocations in lieu of > the customer's address and phone number. The customer's actual > information must be provided to ARIN on request and will be held in the > strictest confidence. > > 8. Rationale: > > Version 2.0 clarifies the need for the customer name to remain in the > SWIP and RWHOIS information. > > Customer contact lists are one of the most proprietary and confidential > pieces of information in any business. The requirements for ISPs to > publish those lists via SWIP or RWHOIS runs contrary to good business > practices and invites competitors and others to solicit both individuals > and companies receiving reassignments and sub allocations from upstream > providers. > > 9. Timetable for implementation: immediate > > Aaron Wendel > Wholesale Internet, Inc. > 324 E. 11th St. Suite 1000 > Kansas City, MO 64106 > 816-256-3031 > > _______________________________________________ > 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 tony at lava.net Fri Jan 29 14:13:31 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 29 Jan 2010 09:13:31 -1000 (HST) Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: References: Message-ID: On Jan 28, 2010, at 5:02 PM, Member Services wrote: > For this petition to be successful, it will need statements of support > from at least 10 different people from 10 different organizations. If > you wish to support this petition, post a statement of support to PPML > on this thread. Point of contact information is required, either to the > entire PPML or with a follow up post to petition at arin.net with full POC > information (name, organization, street address, email, phone). LavaNet supports this petition. Antonio Querubin LavaNet 733 Bishop St. Honolulu, HI 96813 system at lava.net (808) 545-5282 From owen at delong.com Fri Jan 29 14:13:20 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Jan 2010 11:13:20 -0800 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> Message-ID: <62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com> I would like to clarify a couple of points in this discussion... This proposal is a bit more conservative than the one being discussed below. As I understand the NRPM, this proposal would enable customers who can justify a need for 128 or more IP addresses and who are multihomed to get a /24. It would not enable customers with, say, 8 addresses to get a /24 from ARIN, even though they can get a /24 from one of their upstream providers. Thus, this policy only opens up ARIN PI /24s to a subset of those that can currently get PA /24s, and, not everyone. While I would support a policy that had parity with the PA /24 policy for direct assignments from ARIN, I think such a policy would be far less likely to achieve community consensus at this time. Owen On Jan 29, 2010, at 8:41 AM, Jim McBurnett wrote: > Thanks Bill.... > Yes.. I agree with the holding off.. > Also-- Could someone correct me where I stated in the last post IRT the ISP contract requirements as a Multihoming request verification from ARIN? > I think that would help put James at ease.... > > > Thanks! > jim > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin > Sent: Friday, January 29, 2010 11:18 AM > To: Owen DeLong; arin ppml > Subject: Re: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title > > On Fri, Jan 29, 2010 at 8:55 AM, Jim McBurnett wrote: >> Owen, >> Thanks for the reply.. >> I wish I had time and budget to go the meetings.. >> >> I have not seen anymore comments on this... Has an consensus been made? > > Jim, > > I'm waiting for the update to the text that Owen promised to close a > hole in the language that could cause the renumbering and return of > blocks much larger than /20. > > > On Fri, Jan 29, 2010 at 9:36 AM, James Hess wrote: >> The primary concern from a policy perspective to ARIN and to the ISP >> should be to prevent end-users from LYING and showing a network >> design that includes multi-homing, where in fact they have no real >> intention to multihome for the redundancy they claim they want. > > Hi James, > > If you're willing to lie, it's not hard to justify a /22. That's > fraud, however, so if you're found out you could be very suddenly > without the IP addresses critical to your business. High risk for an > insufficient reward. > > Operationally, it just hasn't been a problem. > > If it does become a problem, ARIN can trivially address it outside of > the policy framework. They need only implement a SWIP-like framework > in which each AS providing you with BGP service submits a template > declaring their AS and your ORG. > > Right now, though, that would be a lot of work to implement a > precaution that does not appear necessary. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > 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 telnetcommunications.com Fri Jan 29 14:08:01 2010 From: bill at telnetcommunications.com (Bill Sandiford) Date: Fri, 29 Jan 2010 14:08:01 -0500 Subject: [arin-ppml] Customer Confidentially and IPv6 In-Reply-To: <0E328597-6576-4842-8EF8-6B3FED5EA1B9@delong.com> References: <20100129144811.GA47271@ussenterprise.ufp.org> <0E328597-6576-4842-8EF8-6B3FED5EA1B9@delong.com> Message-ID: I can't specifically speak for Owen, but at the conclusion of his message I believe he meant to say "Toronto" instead of "Dearborn" Regards, Bill From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, January 29, 2010 2:05 PM To: Leo Bicknell Cc: ppml at arin.net Subject: Re: [arin-ppml] Customer Confidentially and IPv6 Well, what happens in IPv6? In the NRPM today, 6.5.4.4 states "All /56 and larger assignments to end sites are required to be registered". So for instance if the cable modem provider today who provides a single dynamic IP via DHCP and puts none of them in SWIP decides to provide every customer with a /48 (as many want them to do) or even a /56, via DHCP-PD they will be required to put those dynamic assignments into SWIP. Actually, as I interpret the NRPM, they would be required to put the covering prefix of the DHCP pool into SWIP as a DHCP Pool, but, there is no need for the DHCP daemon to update SWIPS. If that isn't the case, you are correct that that area of policy needs work. However, for static persistent assignments of /56s or shorter prefixes to customers, I think it is perfectly reasonable to require SWIP just as we require it for /29 and shorter today. I do not see a need to expand customer anonymity beyond the current residential requirement. So we are at a cross roads where we are poised either to add literally tens of millions of records to SWIP and cause a new dump of customer databases to ARIN; or perhaps we will inadvertently force many ISP's to hand out /60's and /64's to customers so they don't have to deal with putting these customers into WHOIS. I think either would be a disservice to the community. I'm uncertain why they couldn't use /57s even if what you say were true, but, again, I think that transient dynamic assignments are not subject to that requirement. Given IPv4's end game is near I don't really care how SWIP gets applied to IPv4 anymore. It is what it is, and there is no reason to revisit the issue. However, IPv6 fundamentally alters some of the arguments used with respect to who is in the database and how they are listed. I think the AC would be wise to take this proposal and use it to foster a discussion of WHOIS in an IPv6 world. Privacy of residential customers has clearly been an ongoing concern in various policies, and if IPv6 lists whole classes of users that are not listed today then the level of concern will likely skyrocket. I find it interesting that you expressed support for the petition in this case. As I understand it, the petition, if it succeeds will bring this IPv4-only proposal to the floor in Dearborn for adoption discussion. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbonser at seven.com Fri Jan 29 14:23:22 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Jan 2010 11:23:22 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <04b401caa113$1c5c1dd0$55145970$@net> References: <234506038-1264739765-cardhu_decombobulator_blackberry.rim.net-1497072405-@bda075.bisx.prod.on.blackberry> <5A6D953473350C4B9995546AFE9939EE081F749C@RWC-EX1.corp.seven.com> <04b401caa113$1c5c1dd0$55145970$@net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F74BB@RWC-EX1.corp.seven.com> > > I don't think we're disagreeing per say. I think we're looking at this > from > different angles. > > There are a couple reasons I chose not to eliminate SWIPs in the > proposal; > One, it would never fly. Well, my thought was that anonymous SWIP is the same as no SWIP for all practical purposes. The notion was to find some way that SOME of your customers could be removed from being trawled via whois (and THAT really seems to be the issue, not SWOP itself) but the ones that I believe must remain public ... the ones not exclusively under your management ... would still have the current registration requirements. The real fix for this is actually the same as it was for telephones but is unworkable for the internet. The fix is to allow a customer, once assigned IP addresses, to keep them if they move just like you can keep your phone number if you change cellular providers. It would, however, cause routing table size explosion and isn't workable with the current state of the art. But it would end people trawling your allocated space looking for your SWIPs because over time that space would scatter. You would no longer have any exclusively allocated space, you would simply hand out initial allocations that would, over time, drift to other providers and theirs would drift into you. And I can understand the kind of business intelligence that can be obtained from this information. I could trend competitors, see which were gaining customers, which were losing customers, etc. And that is, I believe, the real problem here. It isn't SWIP per se, it is who has access to it and for what reasons. Is it in the interests of the community that ARIN provide a resource for commercial entities to collect information on each other? Should they have to pay some price for that information? Should they be denied access? How would it be policed. I believe end users should have quick and ready access to the full POC information of people allocated IP addresses. I don't believe that marketing departments of competing providers should be leveraging that information for their commercial interests. > Plus ARIN still uses SWIP for justification. They don't care who it's > assigned to, just that it's assigned. > > Nothing in my proposal takes away from anything that is already > functional. We disagree here. Yes it does take away from things that are already functional. Someone emailed me this morning that they noticed unfamiliar email activity on their mail server from one of my IP addresses and they wanted to know what it was. They were able to quickly and easily determine who was responsible for that IP address even though it was not from the block I have directly assigned. They were able to quickly locate the contact information for a role account that I monitor and we were able to resolve the issue within five minutes. Under your scenario, they would probably need to open a "ticket" with your abuse process. They would need to get in line behind potentially hundreds of other such tickets that got opened that morning for other customers of yours. They would need to explain the activity, you would then contact me, then there would be back and forth communications between me and the other user with you in the middle. It increases the chances if miscommunications, misunderstandings, and creates more work for everyone involved. > It simply gives the ISP the ability, along with it's customer, to > decide if > the address, phone number and e-mail should be displayed. Name is > still > required. > > Aaron All of the above must, in my opinion, be required. George From owen at delong.com Fri Jan 29 14:24:05 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Jan 2010 11:24:05 -0800 Subject: [arin-ppml] Customer Confidentially and IPv6 In-Reply-To: References: <20100129144811.GA47271@ussenterprise.ufp.org> <0E328597-6576-4842-8EF8-6B3FED5EA1B9@delong.com> Message-ID: <13657810-8F14-4A67-BE85-CB415B835A7A@delong.com> Uh, yeah... OOPS! Yes, the lovely city of Toronto, not Dearborn, MI is correct. Thanks, Bill. Owen On Jan 29, 2010, at 11:08 AM, Bill Sandiford wrote: > I can?t specifically speak for Owen, but at the conclusion of his message I believe he meant to say ?Toronto? instead of ?Dearborn? > > Regards, > Bill > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Friday, January 29, 2010 2:05 PM > To: Leo Bicknell > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Customer Confidentially and IPv6 > > > Well, what happens in IPv6? In the NRPM today, 6.5.4.4 states "All > /56 and larger assignments to end sites are required to be registered". > So for instance if the cable modem provider today who provides a > single dynamic IP via DHCP and puts none of them in SWIP decides > to provide every customer with a /48 (as many want them to do) or > even a /56, via DHCP-PD they will be required to put those dynamic > assignments into SWIP. > > Actually, as I interpret the NRPM, they would be required to put the > covering prefix of the DHCP pool into SWIP as a DHCP Pool, but, > there is no need for the DHCP daemon to update SWIPS. > > If that isn't the case, you are correct that that area of policy needs > work. > > However, for static persistent assignments of /56s or shorter prefixes > to customers, I think it is perfectly reasonable to require SWIP just > as we require it for /29 and shorter today. I do not see a need to > expand customer anonymity beyond the current residential > requirement. > > > So we are at a cross roads where we are poised either to add literally > tens of millions of records to SWIP and cause a new dump of customer > databases to ARIN; or perhaps we will inadvertently force many ISP's > to hand out /60's and /64's to customers so they don't have to deal > with putting these customers into WHOIS. I think either would be > a disservice to the community. > > I'm uncertain why they couldn't use /57s even if what you say were > true, but, again, I think that transient dynamic assignments are not > subject to that requirement. > > Given IPv4's end game is near I don't really care how SWIP gets > applied to IPv4 anymore. It is what it is, and there is no reason > to revisit the issue. However, IPv6 fundamentally alters some of > the arguments used with respect to who is in the database and how > they are listed. I think the AC would be wise to take this proposal > and use it to foster a discussion of WHOIS in an IPv6 world. Privacy > of residential customers has clearly been an ongoing concern in > various policies, and if IPv6 lists whole classes of users that are > not listed today then the level of concern will likely skyrocket. > > I find it interesting that you expressed support for the petition in this > case. As I understand it, the petition, if it succeeds will bring this > IPv4-only proposal to the floor in Dearborn for adoption discussion. > > > Owen > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Fri Jan 29 14:38:38 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 Jan 2010 11:38:38 -0800 Subject: [arin-ppml] Customer Confidentially and IPv6 In-Reply-To: <0E328597-6576-4842-8EF8-6B3FED5EA1B9@delong.com> References: <20100129144811.GA47271@ussenterprise.ufp.org> <0E328597-6576-4842-8EF8-6B3FED5EA1B9@delong.com> Message-ID: <20100129193838.GA75251@ussenterprise.ufp.org> In a message written on Fri, Jan 29, 2010 at 11:04:47AM -0800, Owen DeLong wrote: > Actually, as I interpret the NRPM, they would be required to put the > covering prefix of the DHCP pool into SWIP as a DHCP Pool, but, > there is no need for the DHCP daemon to update SWIPS. > If that isn't the case, you are correct that that area of policy needs > work. Based on what is said in sections 6.5.4.4 and 6.5.5 I don't share your view. It seems to me the manual is clear, if an ISP assigns a /48 to someone then it must be registered via SWIP, with the possible caveat of 6.5.5.1 which allows for the customer name to be replaced with "Private Customer". I don't see anything that would make this not true if the assignment was done via DHCP-PD. > However, for static persistent assignments of /56s or shorter prefixes > to customers, I think it is perfectly reasonable to require SWIP just > as we require it for /29 and shorter today. I do not see a need to > expand customer anonymity beyond the current residential > requirement. Let me assume your previous interpretation is right. A /48 assigned via DHCP-PD to a cable modem customer (as an example) is not required to have a SWIP entry. However, a /48 assigned statically is required to have a SWIP entry. How does that make any sense? What if I make the DHCP-PD "static", e.g. enter the MAC and prefix in the DHCP server, so the client always gets the same range. Does it now qualify for a SWIP entry? In IPv4, it's highly likely that a megacorp (GM?) will have something larger than a /29, and have a SWIP entry. It's also highly likely that a person (residental customer) will have something smaller than a /29, and thus not be SWIPed. As IPv4 scarecity continues, this is likely to be more true. In IPv6 that's not so. The megacorp can likely live in a /48. A residential customer is just as likely to get the same /48. The old probabilities don't apply anymore. In case my position, in both IPv4 and IPv6 was not clear, I believe several things: * No residential customer should ever have their personal information in WHOIS for any reason. * Contact information in whois should lead to the entity /most likely to help/. I am extremely skeptical that putting folks as wide ranging as Grandma to many small businesses is going to lead to that result, I think in almost all cases their upstream ISP is a better place to go. * ARIN should devise policies and procedures such that it requires the minimum level of effort for an ISP to comply. Rather than have millions of /29 records in the database, I'd rather see records like: NetRange: 10.15.0.0 - 10.15.31.255 CIDR: 10.15.0.0/11 NetName: CableFOO-Chicago-12 Comment: Statically assigned residential cable modem customers in the Chicago area. Usage: 212,453 subnets of 262144 in use on 2009-01-29. OrgAbuseHandle: CableFOO-ABUSE-ARIN OrgAbuseName: CableFOO Inc Abuse Department OrgAbusePhone: +1 800 4BOTNET OrgAbuseEmail: abuse-chiago at cablefoo.com Where the usage data was updated on some periodic interval, perhaps say quarterly. It protects peoples privacy, provides usage information ARIN needs and makes it visable to the community, directs people to contact information that is likely to get someone who can help, and greatly reduces the burden on the ISP and ARIN to process tons of SWIP templates, 99% of which just say "Private Customer" and "Private Residence" anyway. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From kkargel at polartel.com Fri Jan 29 14:41:31 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 29 Jan 2010 13:41:31 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <04b401caa113$1c5c1dd0$55145970$@net> References: <234506038-1264739765-cardhu_decombobulator_blackberry.rim.net-1497072405-@bda075.bisx.prod.on.blackberry> <5A6D953473350C4B9995546AFE9939EE081F749C@RWC-EX1.corp.seven.com> <04b401caa113$1c5c1dd0$55145970$@net> Message-ID: <8695009A81378E48879980039EEDAD28876D3F86@MAIL1.polartel.local> > > George, > > I don't think we're disagreeing per say. I think we're looking at this > from > different angles. > > There are a couple reasons I chose not to eliminate SWIPs in the proposal; > One, it would never fly. Two, I have customers that want to be SWIP'd and > are competent to field inquiries into their IP space and 3, I was looking > for a simple proposal that would protect my customer list while still > allowing others to see if a range was allocated, how much of it was > allocated and to who it was allocated (by name). I felt that was a middle > ground that everyone could live with. > > Plus ARIN still uses SWIP for justification. They don't care who it's > assigned to, just that it's assigned. > > Nothing in my proposal takes away from anything that is already > functional. > It simply gives the ISP the ability, along with it's customer, to decide > if > the address, phone number and e-mail should be displayed. Name is still > required. > > Aaron > > I would consider supporting the proposal allowing company anonymity if the proposal maintained a requirement for functional Tech and Abuse contacts with a real telephone number and a real email address. I see no need for a physical or mailing address for these contacts. The Tech and Abuse contacts need to be persons actually affiliated with the network. Either direct employees or a responsible contractor who manages the network would be acceptable. If the ISP manages the network then the ISP would be the appropriate contact, more appropriate in many cases than the company CEO certainly. I realize that at this time the discussion is really about the petition, so I will step back and wait until the proposal itself is being discussed to contribute further. Kevin From bill at herrin.us Fri Jan 29 14:57:02 2010 From: bill at herrin.us (William Herrin) Date: Fri, 29 Jan 2010 14:57:02 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> <62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com> Message-ID: <3c3e3fca1001291157s1c4b9c68rf4f78578ac0aa4d1@mail.gmail.com> On Fri, Jan 29, 2010 at 2:13 PM, Owen DeLong wrote: > As I understand the NRPM, this proposal would enable customers who can justify > a need for 128 or more IP addresses and who are multihomed to get a /24. It would > not enable customers with, say, 8 addresses to get a /24 from ARIN, even though > they can get a /24 from one of their upstream providers. Hi Owen, The governing language is in NRPM 4.3.3 which reads: * A 25% immediate utilization rate, and * A 50% utilization rate within one year. So that's 64 addresses now and an additional 64 within one year. Except of course, nobody will check in a year to see if you used an additional 64 addresses. IMHO, 4.3.3 should probably be tightened up a bit as we approach free pool depletion, perhaps to something like "50% now and 75% in a year" or maybe just "50% now" since we probably aren't going to check in with end-users in a year anyway. Allowing assignments at the /24 level will help us do that since it would no longer have the effect of putting the minimum assignment size out of reach for small multihomed orgs in the "couple hundred people" category. > Thus, this policy only opens up ARIN PI /24s to a subset of those that can currently > get PA /24s, and, not everyone. ?While I would support a policy that had parity with > the PA /24 policy for direct assignments from ARIN, I think such a policy would be > far less likely to achieve community consensus at this time. Concur. Also, I'd like to see whether any problems (e.g. fraud) crop up at this proposal's level so that they can be corrected before attempting for full parity with NRPM 4.2.3.6. I don't anticipate any problems. ARIN's IPv4 process remains arcane enough to do a solid job keeping those without a genuine need at bay. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rudi.daniel at gmail.com Fri Jan 29 14:59:07 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Fri, 29 Jan 2010 15:59:07 -0400 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality Message-ID: <8aeeaff61001291159y7a0da2beka27550728e3abbe3@mail.gmail.com> That is perfectly correct David I also support the petition. I believe that discussion is necessary. We are talking v6 allocations and as such I do not believe for one minute that any of us have all the answers. There is a privacy issue here too and whilst I support the proposal as written, It does not mean that I cannot be swayed. This proposal has to be and needs to be discussed at length so that we can all begin to see the implications now and in an IPv6 world and beyond. RD > > Message: 3 > Date: 28 Jan 2010 21:19:59 -0600 > From: David Farmer > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: > Content-Type: text/plain; format=flowed; charset=UTF-8 > > Several people including Rudy below, have stated that they support the > proposal as written, and that is all well and good. > > I would suggest that if in addition to supporting the text of the proposal > you also support the Petition that is in process, that you should say that > clearly too. I bring this up because it is not impossible for someone to > think this proposal is a good idea, but to not support the Petition. > > As I am on the AC and already had my vote, so I take no position on the > Petition either way, this Petition is for the rest of the community to > decide. > > However, I would just like to make sure we avoid any misunderstandings in > this whole process. > > Thanks > > On Jan 28 2010, Rudolph Daniel wrote: > > >I also support this policy proposal as written. > > > > > >RD > > > > ------------------------------ > > Message: 4 > Date: Thu, 28 Jan 2010 22:20:41 -0500 > From: Steve Bertrand > To: Aaron Wendel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: <4B625409.3030803 at ibctech.ca> > Content-Type: text/plain; charset=ISO-8859-1 > > Aaron Wendel wrote: > > > If you are being scanned by a machine on my network I'm the first, and in > > most cases, the only one that needs to know about it and the only one > that > > can do anything for you. > > I don't think we're going to get anywhere with this policy, because my > objectives have been solely focused on the fact that everyone will > actually create proper SWIP records, and have the same mentality that I > do, that the Internet runs based on the best interest of the community. > > With that said... > > I know how to look up your abuse PoC if the front-desk lady is the > recipient of my phone call when I call the number listed in their SWIP. > I will find you. So will anyone else troubleshooting a problem that > requires digging up whois information. > > You, being a good netizen, having client SWIP info in the database, > allows me to get the information of your client that is attacking me, > and pass it along to a peer in the event that they see the same IP block > attacking them via a different path. Or, if your malicious client signs > up with an SP who also is a good community member, will list the same > info in whois. > > Again, it's unlikely, as I'm slowly loosing faith that all ISPs are good > ISPs :) > > Aside from knowing how to find you without you hiding information, did > you consider what I said earlier about the potential advertisement > stream for your clients that could be whois? > > Perhaps they may *want* to have their info listed. If you really feel > that harvesters can find your clients that easily, perhaps your clients > may believe that they can be found the same way for new revenue/market > streams by potential clients of their own. > > Steve > > > ------------------------------ > > Message: 5 > Date: Thu, 28 Jan 2010 22:24:39 -0500 > From: > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: <9ffde89c9a62405db3c19301c03a0567 at kcix.net> > Content-Type: text/plain; charset=UTF-8 > > I support the petition as well as the proposal. :) > > Todd Bysfield > Kansas City Internet eXchange > 6910 W. 83rd St. > Suite 207 > Overland Park, KS 66204 > http://www.kcix.net > AS40542 > > On 28 Jan 2010 21:19:59 -0600, David Farmer wrote: > > Several people including Rudy below, have stated that they support the > > proposal as written, and that is all well and good. > > > > I would suggest that if in addition to supporting the text of the > proposal > > you also support the Petition that is in process, that you should say > that > > clearly too. I bring this up because it is not impossible for someone to > > > think this proposal is a good idea, but to not support the Petition. > > > > As I am on the AC and already had my vote, so I take no position on the > > Petition either way, this Petition is for the rest of the community to > > decide. > > > > However, I would just like to make sure we avoid any misunderstandings > in > > this whole process. > > > > Thanks > > > > On Jan 28 2010, Rudolph Daniel wrote: > > > >>I also support this policy proposal as written. > >> > >> > >>RD > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > ------------------------------ > > Message: 6 > Date: Thu, 28 Jan 2010 19:29:55 -0800 > From: "George Bonser" > To: "George Bonser" , "Steve Bertrand" > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: > <5A6D953473350C4B9995546AFE9939EE081F7496 at RWC-EX1.corp.seven.com> > Content-Type: text/plain; charset="us-ascii" > > > Because this proposal provides no benefit to the community at large, > > and > > because it has the potential to facilitate abuse of all sorts of other > > policy, I can't support this proposal. > > That said, I would not be opposed to a way to protect the service > providers from someone perusing ARIN information for sales contacts. I > just haven't come up with a good suggestion. Heck, it seems any time I > update anything at ARIN, I get a new blast of sales calls. It is > annoying, I know the sales drones do use ARINs information for sales > contacts. > > You can't allow large providers unfettered access because they are one > of the abusers of the current system. A provider filling a customer > request for a block of addresses should have access to information on > all blocks SWIPed to that customer. An end user attempting to track > down abuse or troubleshooting a problem should be able to determine who > owns a block and what other blocks they own. The idea should not be to > shield an organization from having their network assignments known, but > to shield the provider from having their network space crawled to > determine who their customers are. > > George > > > > > ------------------------------ > > Message: 7 > Date: Thu, 28 Jan 2010 21:30:37 -0600 > From: "Aaron Wendel" > To: "'Steve Bertrand'" > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: <03e401caa093$6cacefb0$4606cf10$@net> > Content-Type: text/plain; charset="US-ASCII" > > The proposal doesn't restrict information an ISP may disclose. Simply > leaves it up to the ISP to decide with their customers and gives them the > same options and protection that access providers (cable companies, DSL > providers and Dial-up operators) currently enjoy. > > Aaron > > > -----Original Message----- > From: Steve Bertrand [mailto:steve at ibctech.ca] > Sent: Thursday, January 28, 2010 9:21 PM > To: Aaron Wendel > Cc: 'George Bonser'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > Aaron Wendel wrote: > > > If you are being scanned by a machine on my network I'm the first, and in > > most cases, the only one that needs to know about it and the only one > that > > can do anything for you. > > I don't think we're going to get anywhere with this policy, because my > objectives have been solely focused on the fact that everyone will > actually create proper SWIP records, and have the same mentality that I > do, that the Internet runs based on the best interest of the community. > > With that said... > > I know how to look up your abuse PoC if the front-desk lady is the > recipient of my phone call when I call the number listed in their SWIP. > I will find you. So will anyone else troubleshooting a problem that > requires digging up whois information. > > You, being a good netizen, having client SWIP info in the database, > allows me to get the information of your client that is attacking me, > and pass it along to a peer in the event that they see the same IP block > attacking them via a different path. Or, if your malicious client signs > up with an SP who also is a good community member, will list the same > info in whois. > > Again, it's unlikely, as I'm slowly loosing faith that all ISPs are good > ISPs :) > > Aside from knowing how to find you without you hiding information, did > you consider what I said earlier about the potential advertisement > stream for your clients that could be whois? > > Perhaps they may *want* to have their info listed. If you really feel > that harvesters can find your clients that easily, perhaps your clients > may believe that they can be found the same way for new revenue/market > streams by potential clients of their own. > > Steve > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/28/10 > 13:36:00 > > > > ------------------------------ > > Message: 8 > Date: Thu, 28 Jan 2010 22:38:00 -0500 > From: Steve Bertrand > To: Aaron Wendel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: <4B625818.4050303 at ibctech.ca> > Content-Type: text/plain; charset=ISO-8859-1 > > Aaron Wendel wrote: > > The proposal doesn't restrict information an ISP may disclose. Simply > > leaves it up to the ISP to decide with their customers and gives them the > > same options and protection that access providers (cable companies, DSL > > providers and Dial-up operators) currently enjoy. > > ...reading this paragraph, you are trying to level a playing field of > sorts... > > I thought that "cable companies, DSL providers and Dial-up operators" > were ISPs... > > My understanding is if an 'ISP' doles out a /29, we have to SWIP it, and > so would anyone else who has IP space allocated by ARIN, no matter what > type of access they provide. > > What am I missing, and what are they enjoying that I'm not? > > I don't SWIP the IPs of my dial up clients, nor my DSL users when they > don't have < /29. > > Steve > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 55, Issue 57 > ***************************************** > -- Rudi Daniel e Business Consultant http://www.svgpso.org http://oecstimes.wordpress.com ?The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.? - Bertrand Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Jan 29 15:25:15 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Jan 2010 12:25:15 -0800 Subject: [arin-ppml] Customer Confidentially and IPv6 In-Reply-To: <20100129193838.GA75251@ussenterprise.ufp.org> References: <20100129144811.GA47271@ussenterprise.ufp.org> <0E328597-6576-4842-8EF8-6B3FED5EA1B9@delong.com> <20100129193838.GA75251@ussenterprise.ufp.org> Message-ID: <5C7BA659-F622-4692-B333-0B8ED8B68EDF@delong.com> On Jan 29, 2010, at 11:38 AM, Leo Bicknell wrote: > In a message written on Fri, Jan 29, 2010 at 11:04:47AM -0800, Owen DeLong wrote: >> Actually, as I interpret the NRPM, they would be required to put the >> covering prefix of the DHCP pool into SWIP as a DHCP Pool, but, >> there is no need for the DHCP daemon to update SWIPS. >> If that isn't the case, you are correct that that area of policy needs >> work. > > Based on what is said in sections 6.5.4.4 and 6.5.5 I don't share > your view. It seems to me the manual is clear, if an ISP assigns > a /48 to someone then it must be registered via SWIP, with the > possible caveat of 6.5.5.1 which allows for the customer name to > be replaced with "Private Customer". > > I don't see anything that would make this not true if the assignment > was done via DHCP-PD. > >> However, for static persistent assignments of /56s or shorter prefixes >> to customers, I think it is perfectly reasonable to require SWIP just >> as we require it for /29 and shorter today. I do not see a need to >> expand customer anonymity beyond the current residential >> requirement. > > Let me assume your previous interpretation is right. A /48 assigned > via DHCP-PD to a cable modem customer (as an example) is not required > to have a SWIP entry. However, a /48 assigned statically is required > to have a SWIP entry. > > How does that make any sense? What if I make the DHCP-PD "static", > e.g. enter the MAC and prefix in the DHCP server, so the client > always gets the same range. Does it now qualify for a SWIP entry? > Yes, I would expect that to require a SWIP. The point is that transient assignments (assignments which can change downstream responsibility on a regular basis) do not make sense to SWIP. While it is true that IPv4 didn't have transient assignments for more than a single address, and IPv6 does, I still think that it is both technically infeasible and practically unreasonable to expect SWIP templates to be submitted to ARIN by DHCP daemons issuing prefixes on a transient basis. If you statically configure the prefix to the MAC address then you should SWIP it at the same time. That's no longer a transient assignment. However, in a case where the assignee is not known until the DHCP daemon makes the assignment, and, where the assignment goes away in a similarly automated fashion at some later date, SWIP does not make sense, IMHO. > In IPv4, it's highly likely that a megacorp (GM?) will have something > larger than a /29, and have a SWIP entry. It's also highly likely > that a person (residental customer) will have something smaller > than a /29, and thus not be SWIPed. As IPv4 scarecity continues, > this is likely to be more true. > Yes. > In IPv6 that's not so. The megacorp can likely live in a /48. A > residential customer is just as likely to get the same /48. The > old probabilities don't apply anymore. > I think it is far more likely that we'll end up with residential customers getting /56s in most cases, but, time will tell. In either case, if a residential customer gets a /48 static assignment, then, they should be SWIP'd just as /29 residential customers are today. I don't see the issue. > In case my position, in both IPv4 and IPv6 was not clear, I believe > several things: > > * No residential customer should ever have their personal information in > WHOIS for any reason. > I'm mostly willing to accept this. I don't believe that the current requirement for City, State, Zip is unreasonable. > * Contact information in whois should lead to the entity /most likely to > help/. I am extremely skeptical that putting folks as wide ranging as > Grandma to many small businesses is going to lead to that result, I > think in almost all cases their upstream ISP is a better place to go. > Yes and no. I think that Contact information serves a multitude of purposes, including a transparency of process and public audit function. As such, I think that having the contact information (within limits) is worth while. I'm not advocating that Grandma be in there (other than as currently required in IPv4), nor am I advocating that the upstream ISP be difficult to find. > * ARIN should devise policies and procedures such that it requires the > minimum level of effort for an ISP to comply. > To some extent, yes. However, I think that transparency in the process and open access to information about utilization of a public resource holds a higher priority than ISP convenience. > Rather than have millions of /29 records in the database, I'd rather see > records like: > > NetRange: 10.15.0.0 - 10.15.31.255 > CIDR: 10.15.0.0/11 > NetName: CableFOO-Chicago-12 > Comment: Statically assigned residential cable modem customers in > the Chicago area. > Usage: 212,453 subnets of 262144 in use on 2009-01-29. > > OrgAbuseHandle: CableFOO-ABUSE-ARIN > OrgAbuseName: CableFOO Inc Abuse Department > OrgAbusePhone: +1 800 4BOTNET > OrgAbuseEmail: abuse-chiago at cablefoo.com > > Where the usage data was updated on some periodic interval, perhaps say > quarterly. > On this we completely disagree. This is far too little information for any form of public audit or research function and it invites abuses such as getting subnets from N providers in order to get N times the amount of address space you can justify. This is likely less of an issue in IPv6, but, it's certainly a concern in IPv4. > It protects peoples privacy, provides usage information ARIN needs and > makes it visable to the community, directs people to contact information > that is likely to get someone who can help, and greatly reduces the > burden on the ISP and ARIN to process tons of SWIP templates, 99% of > which just say "Private Customer" and "Private Residence" anyway. > I think it does not make enough information visible to the community. I think that in the case of a botted host, CableFOO is far less likely to be able to (or willing to) help me get their customer's one of 50 machines disconnected from the net than the customer themselves. Owen From rudi.daniel at gmail.com Fri Jan 29 15:30:35 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Fri, 29 Jan 2010 16:30:35 -0400 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality Message-ID: <8aeeaff61001291230m6ef7a12fy7d33d53d4873c68@mail.gmail.com> What I think is at the center of the debate here is : How much information and what kind of information is to be in the public view. It is not about whether the information exists. ARIN has the information and a provider has collected the information and passed it to ARIN. Now, under what rules and circumstances can/should that information be accessed and by whom and for what purpose. Disclosure on a need to know basis is also something I am not not 100% clear on. If I see an unusual ip on my server, under what circumstances do I need detailed information on who it is allocated to? And how do I efficiently access that information if it is not an open public record. If it were on public record, what level of certainty do I have that the information is accurate? If it is not on public record and I give good reason to access it, then the entity allocated that record has a right to know / have recorded... who accessed the information and when. Where the information is simply public view, there is more room for abuse of that information simply because there are "fewer" controls on what is published. RD L 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: Policy Proposal 95: Customer Confidentiality (George Bonser) > 2. Re: Customer Confidentially and IPv6 (Owen DeLong) > 3. Re: Customer Confidentially and IPv6 (Leo Bicknell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 Jan 2010 11:23:22 -0800 > From: "George Bonser" > To: "Aaron Wendel" > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: > <5A6D953473350C4B9995546AFE9939EE081F74BB at RWC-EX1.corp.seven.com> > Content-Type: text/plain; charset="us-ascii" > > > > > > > I don't think we're disagreeing per say. I think we're looking at > this > > from > > different angles. > > > > There are a couple reasons I chose not to eliminate SWIPs in the > > proposal; > > One, it would never fly. > > Well, my thought was that anonymous SWIP is the same as no SWIP for all > practical purposes. The notion was to find some way that SOME of your > customers could be removed from being trawled via whois (and THAT really > seems to be the issue, not SWOP itself) but the ones that I believe must > remain public ... the ones not exclusively under your management ... > would still have the current registration requirements. > > The real fix for this is actually the same as it was for telephones but > is unworkable for the internet. The fix is to allow a customer, once > assigned IP addresses, to keep them if they move just like you can keep > your phone number if you change cellular providers. It would, however, > cause routing table size explosion and isn't workable with the current > state of the art. But it would end people trawling your allocated space > looking for your SWIPs because over time that space would scatter. You > would no longer have any exclusively allocated space, you would simply > hand out initial allocations that would, over time, drift to other > providers and theirs would drift into you. > > And I can understand the kind of business intelligence that can be > obtained from this information. I could trend competitors, see which > were gaining customers, which were losing customers, etc. And that is, > I believe, the real problem here. It isn't SWIP per se, it is who has > access to it and for what reasons. Is it in the interests of the > community that ARIN provide a resource for commercial entities to > collect information on each other? Should they have to pay some price > for that information? Should they be denied access? How would it be > policed. I believe end users should have quick and ready access to the > full POC information of people allocated IP addresses. I don't believe > that marketing departments of competing providers should be leveraging > that information for their commercial interests. > > > > Plus ARIN still uses SWIP for justification. They don't care who it's > > assigned to, just that it's assigned. > > > > Nothing in my proposal takes away from anything that is already > > functional. > > We disagree here. Yes it does take away from things that are already > functional. Someone emailed me this morning that they noticed > unfamiliar email activity on their mail server from one of my IP > addresses and they wanted to know what it was. They were able to > quickly and easily determine who was responsible for that IP address > even though it was not from the block I have directly assigned. They > were able to quickly locate the contact information for a role account > that I monitor and we were able to resolve the issue within five > minutes. Under your scenario, they would probably need to open a > "ticket" with your abuse process. They would need to get in line behind > potentially hundreds of other such tickets that got opened that morning > for other customers of yours. They would need to explain the activity, > you would then contact me, then there would be back and forth > communications between me and the other user with you in the middle. It > increases the chances if miscommunications, misunderstandings, and > creates more work for everyone involved. > > > It simply gives the ISP the ability, along with it's customer, to > > decide if > > the address, phone number and e-mail should be displayed. Name is > > still > > required. > > > > Aaron > > All of the above must, in my opinion, be required. > > George > > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Jan 2010 11:24:05 -0800 > From: Owen DeLong > To: Bill Sandiford > Cc: "ppml at arin.net" > Subject: Re: [arin-ppml] Customer Confidentially and IPv6 > Message-ID: <13657810-8F14-4A67-BE85-CB415B835A7A at delong.com> > Content-Type: text/plain; charset="windows-1252" > > Uh, yeah... OOPS! Yes, the lovely city of Toronto, not Dearborn, MI is > correct. > > Thanks, Bill. > > Owen > > On Jan 29, 2010, at 11:08 AM, Bill Sandiford wrote: > > > I can?t specifically speak for Owen, but at the conclusion of his message > I believe he meant to say ?Toronto? instead of ?Dearborn? > > > > Regards, > > Bill > > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > > Sent: Friday, January 29, 2010 2:05 PM > > To: Leo Bicknell > > Cc: ppml at arin.net > > Subject: Re: [arin-ppml] Customer Confidentially and IPv6 > > > > > > Well, what happens in IPv6? In the NRPM today, 6.5.4.4 states "All > > /56 and larger assignments to end sites are required to be registered". > > So for instance if the cable modem provider today who provides a > > single dynamic IP via DHCP and puts none of them in SWIP decides > > to provide every customer with a /48 (as many want them to do) or > > even a /56, via DHCP-PD they will be required to put those dynamic > > assignments into SWIP. > > > > Actually, as I interpret the NRPM, they would be required to put the > > covering prefix of the DHCP pool into SWIP as a DHCP Pool, but, > > there is no need for the DHCP daemon to update SWIPS. > > > > If that isn't the case, you are correct that that area of policy needs > > work. > > > > However, for static persistent assignments of /56s or shorter prefixes > > to customers, I think it is perfectly reasonable to require SWIP just > > as we require it for /29 and shorter today. I do not see a need to > > expand customer anonymity beyond the current residential > > requirement. > > > > > > So we are at a cross roads where we are poised either to add literally > > tens of millions of records to SWIP and cause a new dump of customer > > databases to ARIN; or perhaps we will inadvertently force many ISP's > > to hand out /60's and /64's to customers so they don't have to deal > > with putting these customers into WHOIS. I think either would be > > a disservice to the community. > > > > I'm uncertain why they couldn't use /57s even if what you say were > > true, but, again, I think that transient dynamic assignments are not > > subject to that requirement. > > > > Given IPv4's end game is near I don't really care how SWIP gets > > applied to IPv4 anymore. It is what it is, and there is no reason > > to revisit the issue. However, IPv6 fundamentally alters some of > > the arguments used with respect to who is in the database and how > > they are listed. I think the AC would be wise to take this proposal > > and use it to foster a discussion of WHOIS in an IPv6 world. Privacy > > of residential customers has clearly been an ongoing concern in > > various policies, and if IPv6 lists whole classes of users that are > > not listed today then the level of concern will likely skyrocket. > > > > I find it interesting that you expressed support for the petition in this > > case. As I understand it, the petition, if it succeeds will bring this > > IPv4-only proposal to the floor in Dearborn for adoption discussion. > > > > > > Owen > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20100129/47fe4c97/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Fri, 29 Jan 2010 11:38:38 -0800 > From: Leo Bicknell > To: ppml at arin.net > Subject: Re: [arin-ppml] Customer Confidentially and IPv6 > Message-ID: <20100129193838.GA75251 at ussenterprise.ufp.org> > Content-Type: text/plain; charset="us-ascii" > > In a message written on Fri, Jan 29, 2010 at 11:04:47AM -0800, Owen DeLong > wrote: > > Actually, as I interpret the NRPM, they would be required to put the > > covering prefix of the DHCP pool into SWIP as a DHCP Pool, but, > > there is no need for the DHCP daemon to update SWIPS. > > If that isn't the case, you are correct that that area of policy needs > > work. > > Based on what is said in sections 6.5.4.4 and 6.5.5 I don't share > your view. It seems to me the manual is clear, if an ISP assigns > a /48 to someone then it must be registered via SWIP, with the > possible caveat of 6.5.5.1 which allows for the customer name to > be replaced with "Private Customer". > > I don't see anything that would make this not true if the assignment > was done via DHCP-PD. > > > However, for static persistent assignments of /56s or shorter prefixes > > to customers, I think it is perfectly reasonable to require SWIP just > > as we require it for /29 and shorter today. I do not see a need to > > expand customer anonymity beyond the current residential > > requirement. > > Let me assume your previous interpretation is right. A /48 assigned > via DHCP-PD to a cable modem customer (as an example) is not required > to have a SWIP entry. However, a /48 assigned statically is required > to have a SWIP entry. > > How does that make any sense? What if I make the DHCP-PD "static", > e.g. enter the MAC and prefix in the DHCP server, so the client > always gets the same range. Does it now qualify for a SWIP entry? > > In IPv4, it's highly likely that a megacorp (GM?) will have something > larger than a /29, and have a SWIP entry. It's also highly likely > that a person (residental customer) will have something smaller > than a /29, and thus not be SWIPed. As IPv4 scarecity continues, > this is likely to be more true. > > In IPv6 that's not so. The megacorp can likely live in a /48. A > residential customer is just as likely to get the same /48. The > old probabilities don't apply anymore. > > In case my position, in both IPv4 and IPv6 was not clear, I believe > several things: > > * No residential customer should ever have their personal information in > WHOIS for any reason. > > * Contact information in whois should lead to the entity /most likely to > help/. I am extremely skeptical that putting folks as wide ranging as > Grandma to many small businesses is going to lead to that result, I > think in almost all cases their upstream ISP is a better place to go. > > * ARIN should devise policies and procedures such that it requires the > minimum level of effort for an ISP to comply. > > Rather than have millions of /29 records in the database, I'd rather see > records like: > > NetRange: 10.15.0.0 - 10.15.31.255 > CIDR: 10.15.0.0/11 > NetName: CableFOO-Chicago-12 > Comment: Statically assigned residential cable modem customers in > the Chicago area. > Usage: 212,453 subnets of 262144 in use on 2009-01-29. > > OrgAbuseHandle: CableFOO-ABUSE-ARIN > OrgAbuseName: CableFOO Inc Abuse Department > OrgAbusePhone: +1 800 4BOTNET > OrgAbuseEmail: abuse-chiago at cablefoo.com > > Where the usage data was updated on some periodic interval, perhaps say > quarterly. > > It protects peoples privacy, provides usage information ARIN needs and > makes it visable to the community, directs people to contact information > that is likely to get someone who can help, and greatly reduces the > burden on the ISP and ARIN to process tons of SWIP templates, 99% of > which just say "Private Customer" and "Private Residence" anyway. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 826 bytes > Desc: not available > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20100129/f979d8d1/attachment.bin > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 55, Issue 65 > ***************************************** > -- Rudi Daniel e Business Consultant http://www.svgpso.org http://oecstimes.wordpress.com ?The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.? - Bertrand Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at lagniappeinternet.com Fri Jan 29 17:06:58 2010 From: rob at lagniappeinternet.com (Robert Porter) Date: Fri, 29 Jan 2010 16:06:58 -0600 Subject: [arin-ppml] I support the petition to advance proposal 95 Message-ID: <44966bc71001291406m7abc1017rda2211a18f5b837a@mail.gmail.com> I support the petition to advance proposal 95 -------------- next part -------------- An HTML attachment was scrubbed... URL: From crogers at real.com Fri Jan 29 17:45:28 2010 From: crogers at real.com (Christopher Rogers) Date: Fri, 29 Jan 2010 14:45:28 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> Message-ID: <1264805128.10926.1376.camel@fastlane.prognet.com> I OPPOSE this policy proposal as well, for exactly the same reason Bill provides: > > That having been said, I oppose the policy proposal itself. Disclosure > is critical to transparency in ARIN's process. Transparency is far > more important than any corporate desire to avoid competition. Should > the AC ultimately decide not to recommend it to the board on the > grounds that it makes for bad policy, I will support that choice. > > Regards, > Bill Herrin > > > If your business model relies upon hiding spammers and other malcontents- then come up with a new model. Christopher Rogers AS11922 - Real Networks 2601 Elliott Ave Seattle, WA 98121 From tedm at ipinc.net Fri Jan 29 18:11:14 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 15:11:14 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> Message-ID: <4B636B12.6090603@ipinc.net> So far I count 12 solid supporters of the petition. They are: jay at handynetworks.com // Handy Networks LLC joe at joesdatacenter.com // Joe's Datacenter, LLC network at dimenoc.com //DimeNoc AS33182 bicknell at ufp.org - bicknell at ufp.org - CCIE 3440 spamfree at wansecurity.com Robert Smith, CISSP WANSecurity, Inc. dsd at carpathiahost.com Carpathia Hosting, Inc thorsten.ziegler at 1and1.com 1&1 Internet, AS8560 lar at mwtcorp.net ARIN ORG: CBS-129 bill at herrin.us AS 11875 stephen.r.middleton at verizon.com Verizon Services Operations raul at datavo.com Datavo / AS26773 tony at lava.net LavaNet The following people stated they supported the policy but they didn't state that they supported the petition todd at kcix.net The following people supported the petition but didn't identify who they represent: rudi.daniel at gmail.com marty at akamai.com rob at lagniappeinternet.com Naturally the AC will need to make the "official" determination but it looks like we will be discussing this. Marshall your arguments! :-) Ted John Curran wrote: > ARIN Community - > > I am reposting this Petition Announcement under a distinct subject > line as otherwise not all mailing list participants may recognize > that this process is underway. This is neither a statement for or > against the petition, and all statements of support posted under > the original thread or this one will be counted in the total. > > /John > > John Curran > President and CEO > ARIN > > On Jan 28, 2010, at 5:02 PM, Member Services wrote: > >> With the message below a petition has started regarding the ARIN >> Advisory Council's decision to abandon Proposal 95: Customer >> Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the >> ARIN Advisory Council (AC) had decided to abandon the proposal. >> >> If successful, this petition will change Proposal 95 into a Draft Policy >> which will be published for discussion and review by the community on >> the PPML and at the Public Policy Meeting in April. If the petition >> fails, the proposal will be closed. >> >> For this petition to be successful, it will need statements of support >> from at least 10 different people from 10 different organizations. If >> you wish to support this petition, post a statement of support to PPML >> on this thread. Point of contact information is required, either to the >> entire PPML or with a follow up post to petition at arin.net with full POC >> information (name, organization, street address, email, phone). >> >> The duration of the petition is five business days; it will end on 4 >> February 2010. ARIN staff will post the result of the petition to PPML. >> >> For more information on starting and participating in petitions, see PDP >> Petitions at: https://www.arin.net/policy/pdp_petitions.html >> >> The proposal text is below and 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, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> ##### >> >> Aaron Wendel wrote: >>> I do not feel the AC should abandon Policy Proposal 95: Customer >>> Confidentiality. I formally petition to move the following text forward for >>> discussion on the list and at the next Public Policy Meeting. I would >>> appreciate it if anyone this policy applies to would support moving this >>> proposal forward by posting statements in support of the petition to this >>> list. >>> >>> 1. Policy Proposal Name: Customer Confidentiality >>> >>> 2. Proposal Originator: Aaron Wendel >>> >>> 3. Proposal Version: 2.0 >>> >>> 4. Date: 10 June 2009 >>> >>> 5. Proposal type: new >>> >>> 6. Policy term: permanent >>> >>> 7. Policy statement: >>> >>> ISPs may choose to enter the customer's name along with the ISP's >>> address and phone number in reassignments and reallocations in lieu of >>> the customer's address and phone number. The customer's actual >>> information must be provided to ARIN on request and will be held in the >>> strictest confidence. >>> >>> 8. Rationale: >>> >>> Version 2.0 clarifies the need for the customer name to remain in the >>> SWIP and RWHOIS information. >>> >>> Customer contact lists are one of the most proprietary and confidential >>> pieces of information in any business. The requirements for ISPs to >>> publish those lists via SWIP or RWHOIS runs contrary to good business >>> practices and invites competitors and others to solicit both individuals >>> and companies receiving reassignments and sub allocations from upstream >>> providers. >>> >>> 9. Timetable for implementation: immediate >>> >>> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 >>> Kansas City, MO 64106 >>> 816-256-3031 >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >>> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jay at handynetworks.com Fri Jan 29 18:21:00 2010 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Fri, 29 Jan 2010 23:21:00 +0000 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <1264805128.10926.1376.camel@fastlane.prognet.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> <1264805128.10926.1376.camel@fastlane.prognet.com> Message-ID: <1BC378592675E040B37CD2AE7C0A542A6451B7@OfficeExch2k7A.exchange.handynetworks.com> Christopher - Those of us who support this petition and proposal do not have a business model that rely on hiding spammers and other nefarious actors. Your comment is insulting, and does nothing to further the discussion on this topic. -Jay -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Rogers Sent: Friday, January 29, 2010 3:45 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality If your business model relies upon hiding spammers and other malcontents- then come up with a new model. Christopher Rogers AS11922 - Real Networks 2601 Elliott Ave Seattle, WA 98121 _______________________________________________ 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 joe at joesdatacenter.com Fri Jan 29 18:07:42 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Fri, 29 Jan 2010 17:07:42 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <1264805128.10926.1376.camel@fastlane.prognet.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> <1264805128.10926.1376.camel@fastlane.prognet.com> Message-ID: <38dd4e411001291507q376d188aq26be74b8f798a02f@mail.gmail.com> I don't think policy in any way helps hide spammers or make customer base transparent. It only keeps customer contact information private not the customer themselves. I urge people to actually read the policy before making assumptions and claiming that it will do things it will not. The fact that the argument keeps coming back to this only shows that you are not educating yourself enough on the topic at hand. Please explain how this would help hide a spammer? If I was going to hide a spammer would I provide the actual swip information in the first place? Maybe you should start a policy to have each swip verified for accuracy before being placed on the public list. This would be more in line with what you seem to be wanting. I still do not see how this policy has anything to do with what your talking about. On Fri, Jan 29, 2010 at 4:45 PM, Christopher Rogers wrote: > I OPPOSE this policy proposal as well, for exactly the same reason Bill > provides: > > >> >> That having been said, I oppose the policy proposal itself. Disclosure >> is critical to transparency in ARIN's process. Transparency is far >> more important than any corporate desire to avoid competition. Should >> the AC ultimately decide not to recommend it to the board on the >> grounds that it makes for bad policy, I will support that choice. >> >> Regards, >> Bill Herrin >> >> >> > > If your business model relies upon hiding spammers and other > malcontents- then come up with a new model. > > Christopher Rogers > AS11922 - Real Networks > 2601 Elliott Ave > Seattle, WA 98121 > > > > _______________________________________________ > 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. > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From aaron at wholesaleinternet.net Fri Jan 29 18:32:18 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 29 Jan 2010 17:32:18 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B636B12.6090603@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> Message-ID: <05a901caa13b$4cd154d0$e673fe70$@net> I, of course, support my own petition although I don't know if I officially count. It's unclear whether the 10 required supporters are in addition to the petitioner or including. I believe Todd @ kcix posted a second time supporting the petition and the proposal. At the very least the requirement for the petition to succeed is 10 people from unique orgs. I count 17 at this point that have posted publically. As for discussion on the proposal itself my running count is 16 for and 5, including you, against. Whether this proposal eventually passes a vote or not it seems to be bringing some new faces to the table and nothing bad can come from increasing the gene pool around here. :) Aaron -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Friday, January 29, 2010 5:11 PM To: arin-ppml at arin.net Cc: John Curran Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive So far I count 12 solid supporters of the petition. They are: jay at handynetworks.com // Handy Networks LLC joe at joesdatacenter.com // Joe's Datacenter, LLC network at dimenoc.com //DimeNoc AS33182 bicknell at ufp.org - bicknell at ufp.org - CCIE 3440 spamfree at wansecurity.com Robert Smith, CISSP WANSecurity, Inc. dsd at carpathiahost.com Carpathia Hosting, Inc thorsten.ziegler at 1and1.com 1&1 Internet, AS8560 lar at mwtcorp.net ARIN ORG: CBS-129 bill at herrin.us AS 11875 stephen.r.middleton at verizon.com Verizon Services Operations raul at datavo.com Datavo / AS26773 tony at lava.net LavaNet The following people stated they supported the policy but they didn't state that they supported the petition todd at kcix.net The following people supported the petition but didn't identify who they represent: rudi.daniel at gmail.com marty at akamai.com rob at lagniappeinternet.com Naturally the AC will need to make the "official" determination but it looks like we will be discussing this. Marshall your arguments! :-) Ted John Curran wrote: > ARIN Community - > > I am reposting this Petition Announcement under a distinct subject > line as otherwise not all mailing list participants may recognize > that this process is underway. This is neither a statement for or > against the petition, and all statements of support posted under > the original thread or this one will be counted in the total. > > /John > > John Curran > President and CEO > ARIN > > On Jan 28, 2010, at 5:02 PM, Member Services wrote: > >> With the message below a petition has started regarding the ARIN >> Advisory Council's decision to abandon Proposal 95: Customer >> Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the >> ARIN Advisory Council (AC) had decided to abandon the proposal. >> >> If successful, this petition will change Proposal 95 into a Draft Policy >> which will be published for discussion and review by the community on >> the PPML and at the Public Policy Meeting in April. If the petition >> fails, the proposal will be closed. >> >> For this petition to be successful, it will need statements of support >> from at least 10 different people from 10 different organizations. If >> you wish to support this petition, post a statement of support to PPML >> on this thread. Point of contact information is required, either to the >> entire PPML or with a follow up post to petition at arin.net with full POC >> information (name, organization, street address, email, phone). >> >> The duration of the petition is five business days; it will end on 4 >> February 2010. ARIN staff will post the result of the petition to PPML. >> >> For more information on starting and participating in petitions, see PDP >> Petitions at: https://www.arin.net/policy/pdp_petitions.html >> >> The proposal text is below and 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, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> ##### >> >> Aaron Wendel wrote: >>> I do not feel the AC should abandon Policy Proposal 95: Customer >>> Confidentiality. I formally petition to move the following text forward for >>> discussion on the list and at the next Public Policy Meeting. I would >>> appreciate it if anyone this policy applies to would support moving this >>> proposal forward by posting statements in support of the petition to this >>> list. >>> >>> 1. Policy Proposal Name: Customer Confidentiality >>> >>> 2. Proposal Originator: Aaron Wendel >>> >>> 3. Proposal Version: 2.0 >>> >>> 4. Date: 10 June 2009 >>> >>> 5. Proposal type: new >>> >>> 6. Policy term: permanent >>> >>> 7. Policy statement: >>> >>> ISPs may choose to enter the customer's name along with the ISP's >>> address and phone number in reassignments and reallocations in lieu of >>> the customer's address and phone number. The customer's actual >>> information must be provided to ARIN on request and will be held in the >>> strictest confidence. >>> >>> 8. Rationale: >>> >>> Version 2.0 clarifies the need for the customer name to remain in the >>> SWIP and RWHOIS information. >>> >>> Customer contact lists are one of the most proprietary and confidential >>> pieces of information in any business. The requirements for ISPs to >>> publish those lists via SWIP or RWHOIS runs contrary to good business >>> practices and invites competitors and others to solicit both individuals >>> and companies receiving reassignments and sub allocations from upstream >>> providers. >>> >>> 9. Timetable for implementation: immediate >>> >>> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 >>> Kansas City, MO 64106 >>> 816-256-3031 >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >>> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/29/10 03:08:00 From tedm at ipinc.net Fri Jan 29 18:35:47 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 15:35:47 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <1BC378592675E040B37CD2AE7C0A542A6451B7@OfficeExch2k7A.exchange.handynetworks.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> <1264805128.10926.1376.camel@fastlane.prognet.com> <1BC378592675E040B37CD2AE7C0A542A6451B7@OfficeExch2k7A.exchange.handynetworks.com> Message-ID: <4B6370D3.6080800@ipinc.net> Jay, please knock off with the melodrama. Christopher was slamming Bill who is an OPPONENT of this policy. You never heard of the enemy of my enemy is my friend, theory? The supporters of this proposal - who you count yourself in - have won a little victory here. It is not necessary for you to roll around in the mud too - at least, not yet ;-). Ted Jay Sudowski - Handy Networks LLC wrote: > Christopher - > > Those of us who support this petition and proposal do not have a business model that rely on hiding spammers and other nefarious actors. Your comment is insulting, and does nothing to further the discussion on this topic. > > -Jay > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Rogers > Sent: Friday, January 29, 2010 3:45 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > > If your business model relies upon hiding spammers and other > malcontents- then come up with a new model. > > Christopher Rogers > AS11922 - Real Networks > 2601 Elliott Ave > Seattle, WA 98121 > > > > _______________________________________________ > 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 tedm at ipinc.net Fri Jan 29 18:54:11 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 15:54:11 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <05a901caa13b$4cd154d0$e673fe70$@net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net> Message-ID: <4B637523.1070708@ipinc.net> Aaron Wendel wrote: > I, of course, support my own petition although I don't know if I officially > count. It's unclear whether the 10 required supporters are in addition to > the petitioner or including. I also noticed that was open to interpretation in the Member Services announcement. > I believe Todd @ kcix posted a second time > supporting the petition and the proposal. > Yup, he did, I missed that. > At the very least the requirement for the petition to succeed is 10 people > from unique orgs. I count 17 at this point that have posted publically. > I looked specifically for people saying they supported the PETITION not for people saying they supported the proposal, or the idea. You can support the idea but not the proposal. I definitely don't support the proposal. I am willing to look at the idea, however. If you can make a logical argument that the current policy as written makes it impossible for ISP's to exclude private individuals or residences in certain circumstances, I'd support a modification to current policy. The current proposal 95 is too simplistic for this, it is applying a paint roller when an artists brush MIGHT be called for. > As for discussion on the proposal itself my running count is 16 for and 5, > including you, against. > That is incorrect. I supported the AC's decision to abandon this and still do. However that does not mean I don't support the petition. I am, in fact, neutral on the petition itself. You and the other supporters want to re-open discussion, because you clearly aren't willing to re-read the archives as to why this kind of proposal is generally a bad idea. Well, OK. I guess sometimes people don't want to read boring old archives and prefer the lively give and take of discussion. I think it's a diverting waste of time but since there's enough people that appear to need it, I'll do my duty as an opponent and try to show you of the error of your ways. Just be warned that those who refuse to learn the lessons of history are doomed to repeat them. > Whether this proposal eventually passes a vote or not it seems to be > bringing some new faces to the table and nothing bad can come from > increasing the gene pool around here. :) > Quite true. And I would never presume to assume that the NRPM is perfect as it is. There's always room for adjustments. Ted > Aaron > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Friday, January 29, 2010 5:11 PM > To: arin-ppml at arin.net > Cc: John Curran > Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: Customer > Confidentiality - Time Sensitive > > > So far I count 12 solid supporters of the petition. > > They are: > > jay at handynetworks.com // Handy Networks LLC > joe at joesdatacenter.com // Joe's Datacenter, LLC > network at dimenoc.com //DimeNoc AS33182 > bicknell at ufp.org - bicknell at ufp.org - CCIE 3440 > spamfree at wansecurity.com Robert Smith, CISSP WANSecurity, Inc. > dsd at carpathiahost.com Carpathia Hosting, Inc > thorsten.ziegler at 1and1.com 1&1 Internet, AS8560 > lar at mwtcorp.net ARIN ORG: CBS-129 > bill at herrin.us AS 11875 > stephen.r.middleton at verizon.com Verizon Services Operations > raul at datavo.com Datavo / AS26773 > tony at lava.net LavaNet > > > The following people stated they supported the policy but they > didn't state that they supported the petition > > todd at kcix.net > > The following people supported the petition but didn't identify > who they represent: > > rudi.daniel at gmail.com > marty at akamai.com > rob at lagniappeinternet.com > > Naturally the AC will need to make the "official" determination > but it looks like we will be discussing this. > > Marshall your arguments! :-) > > Ted > > > John Curran wrote: >> ARIN Community - >> >> I am reposting this Petition Announcement under a distinct subject >> line as otherwise not all mailing list participants may recognize >> that this process is underway. This is neither a statement for or >> against the petition, and all statements of support posted under >> the original thread or this one will be counted in the total. >> >> /John >> >> John Curran >> President and CEO >> ARIN >> >> On Jan 28, 2010, at 5:02 PM, Member Services wrote: >> >>> With the message below a petition has started regarding the ARIN >>> Advisory Council's decision to abandon Proposal 95: Customer >>> Confidentiality. ARIN staff posted on 21 January 2010 to PPML that the >>> ARIN Advisory Council (AC) had decided to abandon the proposal. >>> >>> If successful, this petition will change Proposal 95 into a Draft Policy >>> which will be published for discussion and review by the community on >>> the PPML and at the Public Policy Meeting in April. If the petition >>> fails, the proposal will be closed. >>> >>> For this petition to be successful, it will need statements of support >>> from at least 10 different people from 10 different organizations. If >>> you wish to support this petition, post a statement of support to PPML >>> on this thread. Point of contact information is required, either to the >>> entire PPML or with a follow up post to petition at arin.net with full POC >>> information (name, organization, street address, email, phone). >>> >>> The duration of the petition is five business days; it will end on 4 >>> February 2010. ARIN staff will post the result of the petition to PPML. >>> >>> For more information on starting and participating in petitions, see PDP >>> Petitions at: https://www.arin.net/policy/pdp_petitions.html >>> >>> The proposal text is below and 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, >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> ##### >>> >>> Aaron Wendel wrote: >>>> I do not feel the AC should abandon Policy Proposal 95: Customer >>>> Confidentiality. I formally petition to move the following text forward > for >>>> discussion on the list and at the next Public Policy Meeting. I would >>>> appreciate it if anyone this policy applies to would support moving this >>>> proposal forward by posting statements in support of the petition to > this >>>> list. >>>> >>>> 1. Policy Proposal Name: Customer Confidentiality >>>> >>>> 2. Proposal Originator: Aaron Wendel >>>> >>>> 3. Proposal Version: 2.0 >>>> >>>> 4. Date: 10 June 2009 >>>> >>>> 5. Proposal type: new >>>> >>>> 6. Policy term: permanent >>>> >>>> 7. Policy statement: >>>> >>>> ISPs may choose to enter the customer's name along with the ISP's >>>> address and phone number in reassignments and reallocations in lieu of >>>> the customer's address and phone number. The customer's actual >>>> information must be provided to ARIN on request and will be held in the >>>> strictest confidence. >>>> >>>> 8. Rationale: >>>> >>>> Version 2.0 clarifies the need for the customer name to remain in the >>>> SWIP and RWHOIS information. >>>> >>>> Customer contact lists are one of the most proprietary and confidential >>>> pieces of information in any business. The requirements for ISPs to >>>> publish those lists via SWIP or RWHOIS runs contrary to good business >>>> practices and invites competitors and others to solicit both individuals >>>> and companies receiving reassignments and sub allocations from upstream >>>> providers. >>>> >>>> 9. Timetable for implementation: immediate >>>> >>>> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St. Suite 1000 >>>> Kansas City, MO 64106 >>>> 816-256-3031 >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/29/10 > 03:08:00 > From aaron at wholesaleinternet.net Fri Jan 29 19:12:14 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 29 Jan 2010 18:12:14 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B637523.1070708@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net> <4B637523.1070708@ipinc.net> Message-ID: <05da01caa140$e111f5f0$a335e1d0$@net> >You can support the idea but not the proposal. I definitely don't >support the proposal. I am willing to look at the idea, however. If >you can make a logical argument that the current policy as written >makes it impossible for ISP's to exclude private individuals or >residences in certain circumstances, I'd support a modification to >current policy. I'm not sure I understand what you mean. Residential customers are already covered under a separate policy allowing them to be deemed "private". My proposal provides equal protection for hosted and collocated customers. >You and the other supporters want to re-open discussion, because you >clearly aren't willing to re-read the archives as to why this kind >of proposal is generally a bad idea. Well, OK. I guess sometimes >people don't want to read boring old archives and prefer the lively >give and take of discussion. I think it's >a diverting waste of time but since there's enough people that appear >to need it, I'll do my duty as an opponent and try to show you of >the error of your ways. And on this I will go so far as to say you have no idea what you're talking about. I've read all the archives from 6 years ago. I don't agree with the conclusion, feel that it is outdated and that ARIN membership and participation has changed significantly enough that this topic deserves revisiting. I've talked to many people who think this policy already exists and when they are educated can't believe how stupid it is that it doesn't. The previous proposal that failed is from 2004. It failed 20-7. 27 votes. Almost that many people have weighed in on this topic just in the last 24 hours. I feel it deserves to go to a vote. Hopefully, in the mean time, we can have a reasonable discussion on the topic without people calling other people spammers, child molesters or communists and come to a compromise that everyone can live with. Aaron From mysidia at gmail.com Fri Jan 29 19:17:30 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 29 Jan 2010 18:17:30 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local> <4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com> <38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com> <38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> Message-ID: <6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com> On Fri, Jan 29, 2010 at 2:01 AM, Joe Morgan wrote: > I am accountable for the utilization of the resources allocated to me > by arin already. Saying that anyone utilizing a small fraction of it > should be publicly known is a opinion not a fact. I'm only making this It's a fact that their contact information must be available for them to be contacted related to abuse, connectivity, or other issues impacting THEIR network, or services offered thereby. For some issues, the contact info of an upstream provider _might_ be acceptable, but only if you manage their network and have admin access to their servers. You as upstream cannot assist, if a network device outside of your management is impacting their connectivity to another peer, or a misconfigured firewall is making their DNS server unavailable to someone who needs to send them mail. Please see RFC 1173, Section 3. " 3. Responsibilities of Host System Managers One or more individuals must be responsible for every host connected to the Internet. This person MUST have the authority, access and tools necessary to configure, operate and control access to the system. For important timesharing hosts, primary domain name servers and mail relays or gateways, responsible individual(s) SHOULD be accessible via telephone 24 hours a day, 7 days a week. Read more: http://www.faqs.org/rfcs/rfc1173.html#ixzz0e39aoGX7 " -- -J From jay at handynetworks.com Fri Jan 29 19:23:41 2010 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Sat, 30 Jan 2010 00:23:41 +0000 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B6370D3.6080800@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> <1264805128.10926.1376.camel@fastlane.prognet.com> <1BC378592675E040B37CD2AE7C0A542A6451B7@OfficeExch2k7A.exchange.handynetworks.com> <4B6370D3.6080800@ipinc.net> Message-ID: <1BC378592675E040B37CD2AE7C0A542A646951@OfficeExch2k7A.exchange.handynetworks.com> Ted - PPML is melodrama/ideologue central, and the pair of comments (Chris's and mine) hardly raise to the level of the actual melodrama I have read on this list in the past several years. I just don't appreciate the insinuation that because I, or anyone, wants to protect their customer database from being pilfered from WHOIS is actually simply hiding their bad apple customers from the larger Internet. Eish ... -Jay -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Friday, January 29, 2010 4:36 PM To: Jay Sudowski - Handy Networks LLC Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality Jay, please knock off with the melodrama. Christopher was slamming Bill who is an OPPONENT of this policy. You never heard of the enemy of my enemy is my friend, theory? The supporters of this proposal - who you count yourself in - have won a little victory here. It is not necessary for you to roll around in the mud too - at least, not yet ;-). Ted Jay Sudowski - Handy Networks LLC wrote: > Christopher - > > Those of us who support this petition and proposal do not have a business model that rely on hiding spammers and other nefarious actors. Your comment is insulting, and does nothing to further the discussion on this topic. > > -Jay > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Rogers > Sent: Friday, January 29, 2010 3:45 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > > If your business model relies upon hiding spammers and other > malcontents- then come up with a new model. > > Christopher Rogers > AS11922 - Real Networks > 2601 Elliott Ave > Seattle, WA 98121 > > > > _______________________________________________ > 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 gbonser at seven.com Fri Jan 29 19:25:22 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Jan 2010 16:25:22 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> <6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com> > > You as upstream cannot assist, if a network device outside of your > management is impacting their connectivity to another peer, or > a misconfigured firewall is making their DNS server unavailable > to someone who needs to send them mail. > > > Please see RFC 1173, Section 3. Exactly. Unless the provider is doing 100% managed services for all hosts in that net block, calling the provider is usually a waste of time. What if that block of IP addresses is actually in use in someone else's colo or back at the customer's office? What is the provider going to do except (hopefully) give you the information you should have already been able to get. And what if it is midnight local on a weekend? Is the person on duty going to know that they are even allowed to give out the customer contact info? There are so many problems with this at so many levels for no other reason than to protect someone's customer list and absolutely no benefit to any other segment of the community. From joe at joesdatacenter.com Fri Jan 29 19:21:58 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Fri, 29 Jan 2010 18:21:58 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <05da01caa140$e111f5f0$a335e1d0$@net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net> <4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net> Message-ID: <38dd4e411001291621o6c52fc36m1344d96706fb8579@mail.gmail.com> I still have yet to find a good example of how this policy would be bad. They either make it out as something its not by not reading the policy in full or just make wild accusations that make no real world sense. When pointed out to me I also read the previous articles and still feel this needs to be discussed and changed. I see no way this would hide malicious users and I still do not see any way I could hide a customer under this policy? The only thing this really changes is my providing my customers phone number and address that's it. I still would have to swip my ranges and I would still have to provide the customers name. I honestly believe the only reason people have a issue with this policy is they either do not understand it or they are not going to be effected by it anyway so they don't see the real reasoning behind changing it. How many people against actually even swip ips? On Fri, Jan 29, 2010 at 6:12 PM, Aaron Wendel wrote: > >>You can support the idea but not the proposal. ?I definitely don't >>support the proposal. ?I am willing to look at the idea, however. ?If >>you can make a logical argument that the current policy as written >>makes it impossible for ISP's to exclude private individuals or >>residences in certain circumstances, I'd support a modification to >>current policy. > > I'm not sure I understand what you mean. ?Residential customers are already > covered under a separate policy allowing them to be deemed "private". ?My > proposal provides equal protection for hosted and collocated customers. > >>You and the other supporters want to re-open discussion, because you >>clearly aren't willing to re-read the archives as to why this kind >>of proposal is generally a bad idea. ?Well, OK. ?I guess sometimes >>people don't want to read boring old archives and prefer the lively >>give and take of discussion. ?I think it's >>a diverting waste of time but since there's enough people that appear >>to need it, I'll do my duty as an opponent and try to show you of >>the error of your ways. > > And on this I will go so far as to say you have no idea what you're talking > about. ?I've read all the archives from 6 years ago. ?I don't agree with the > conclusion, feel that it is outdated and that ARIN membership and > participation has changed significantly enough that this topic deserves > revisiting. ?I've talked to many people who think this policy already exists > and when they are educated can't believe how stupid it is that it doesn't. > The previous proposal that failed is from 2004. ?It failed 20-7. ?27 votes. > Almost that many people have weighed in on this topic just in the last 24 > hours. ?I feel it deserves to go to a vote. > > Hopefully, in the mean time, we can have a reasonable discussion on the > topic without people calling other people spammers, child molesters or > communists and come to a compromise that everyone can live with. > > Aaron > > > _______________________________________________ > 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. > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From aaron at wholesaleinternet.net Fri Jan 29 19:37:26 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 29 Jan 2010 18:37:26 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> <6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com> Message-ID: <060b01caa144$66614820$3323d860$@net> What is the proposal distinguished between "Hosted" customers and "Downstream" customers? Meaning that if they have infrastructure in a datacenter you control verses receive transit service from you in their own facility. What would you think of that? Aaron -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of George Bonser Sent: Friday, January 29, 2010 6:25 PM To: James Hess; Joe Morgan Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > You as upstream cannot assist, if a network device outside of your > management is impacting their connectivity to another peer, or > a misconfigured firewall is making their DNS server unavailable > to someone who needs to send them mail. > > > Please see RFC 1173, Section 3. Exactly. Unless the provider is doing 100% managed services for all hosts in that net block, calling the provider is usually a waste of time. What if that block of IP addresses is actually in use in someone else's colo or back at the customer's office? What is the provider going to do except (hopefully) give you the information you should have already been able to get. And what if it is midnight local on a weekend? Is the person on duty going to know that they are even allowed to give out the customer contact info? There are so many problems with this at so many levels for no other reason than to protect someone's customer list and absolutely no benefit to any other segment of the community. _______________________________________________ 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. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/29/10 13:35:00 From bill at herrin.us Fri Jan 29 19:41:56 2010 From: bill at herrin.us (William Herrin) Date: Fri, 29 Jan 2010 19:41:56 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <38dd4e411001291507q376d188aq26be74b8f798a02f@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> <1264805128.10926.1376.camel@fastlane.prognet.com> <38dd4e411001291507q376d188aq26be74b8f798a02f@mail.gmail.com> Message-ID: <3c3e3fca1001291641o5d40541ehd100049457ed2e13@mail.gmail.com> On Fri, Jan 29, 2010 at 6:07 PM, Joe Morgan wrote: > If I was going to hide a spammer would I provide the actual swip > information in the first place? Certainly. If you were clever about it, you'd SWIP it to look like a bunch of entirely different residential customers. If you were subtle about it, you could keep the antispam folks chasing their tails for weeks before they started to smell a rat. SWIP's point is to "keep honest people honest." You cook the books in plain view and sooner or later someone will poke around and realize something isn't right. So you don't cook the books. You pad your requests a little bit, maybe you're a bit tardy deallocating departed customers, but you don't make a big hoarding grab. And you can have confidence that no one else will either because they have the same hurdle you do. Hide enough information to make public audits impossible and you defeat the whole point of SWIP. I can't read a list of nothing but names and make any sort of reasonable assessment whether they're legit. Neither can you. And ARIN isn't actively trolling for fraud; they rely on members of the community realizing that something is squirrelly and reporting it. Anyway, that's why I oppose this proposal... Not because it's proponents are anything but honest but because I'd like to see them continue to be honest. And I'd like to see any of the proponents competitors who would abuse the process to gain advantage fail. There is a point worth introducing to the conversation: last I checked, trolling the whois records for the purpose of making solicitations is against the rules. If you catch someone at it, you ought to report them to ARIN. Anyone going after your static-IP'ed customers will need to have IPs of their own, making them subject to ARIN's enforcement. If ARIN's penalties opposing whois misuse is not performing well enough, perhaps we should look at some policy proposals to correct that more directly. How about something like this: "ISPs may designate up to 2% of the addresses used for internal infrastructure to be published in whois intentionally misidentified as an end user. Such records shall be bait for the purpose of catching those who misuse the whois facility to solicit business. Any ARIN member caught soliciting such a bait record shall pay damages to both ARIN and the offended ISP consistent with the expectation that they have similarly solicited all of the offended ISP's customers. Chronic repeat offenders shall forfeit their number resources." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jim at tgasolutions.com Fri Jan 29 19:46:59 2010 From: jim at tgasolutions.com (Jim McBurnett) Date: Fri, 29 Jan 2010 19:46:59 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <3c3e3fca1001291157s1c4b9c68rf4f78578ac0aa4d1@mail.gmail.com> References: <4B58C4A5.2000406@arin.net> <017265BF3B9640499754DD48777C3D206717F0A191@MBX9.EXCHPROD.USA.NET> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> <62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com> <3c3e3fca1001291157s1c4b9c68rf4f78578ac0aa4d1@mail.gmail.com> Message-ID: Bill, Owen, A few points here: 1. If an end user gets a /24 IP address space from an ISP via the /24 MH rule-- Why such a big difference in PA from ARIN? Yes, I understand-- portable, and not enforced by ARIN for usage. BUT does the ISP check usage? ARIN will enforce tighter rules for themselves than an ISP will? Is IP space usage, regardless of issuing organization, still usage? If I get a /24 from an ISP, and only use /26 of it, is that any better than the same from ARIN? Also what about route table growth? See below.. 2. If I am going to get a /24 to multi-home for an end user, they will use at least 64. BUT do we have a formal definition of usage? See below.. 3. Fraud-- Please correct me if I am wrong here.. BUT isn't there a requirement now for a C Level or VP To put their John Hancock on the request? For Fraud to be a reason to vote this down is wrong. IMHO Attempts to make rules to account for fraud can never include all the variables to be worth the time. 4. Usage-- I have never seen a clear definition of usage. Is it publicly accessible devices? Or NAT pools? Or association with an IP? Or just someone provide host names to X system? 5. De-aggregation-- If I am an ISP today and I have a /16. And I have to de-aggregate a block of say /19 to give a /24 for an end user.. How much growth do I add to the global route table ? how much if a block of say /16 is used by ARIN to give /24's to end users? What is the net effect for the global route table? I suspect that "explosive" growth from an ISP dropping the aggregation would be far worse Than the issuing of IP PA space by ARIN even if an end user is only going to 100% use a /26...... Isn't this route table growth the biggest concern? Do we expect a land rush for IP space if this is passed? From an ISP perspective, what would you rather do? Announce 10 IP blocks in varying lengths because of 1 end user? Or have that 1 end user Get PA space and you announce 2 blocks (1 aggregate and 1 /24) 6. End-user requirements for the space.. On the customers that I have gotten /22s for, we were required to provide reverse DNS for the space-- I would assume even a /24 require the same. With this requirement, won't this help to flush out those that really don't have the ability to handle a /24? A couple of real world problems I see today: 1. Small ISP-- has a /22 today-- has used approx 65%. Their space is segmented in such a way where there is not space to provide a /26 to either end user. They have 2 downstream customers that want a /24 each--they told me they are going to Multi-Home. But as a small organization, renumbering twice (1 to go to this ISP, and again for a /24 would be burdensome) The current ISP, is leaving the area... They are local cable / wireless service providers... ~100 subscribers give or take each. The ISP is a non-profit that provides service to organizations in the area.. They asked ARIN for more IP space to help the end users, got shot down. The end users are too small to get the space from ARIN under today's rules. So what happens? The end users get several /27s from the small ISP and can't multihome... and then get forced to renumber later. What would I hope? The ISP could get that /24 or the end user can sign 2 upstreams and get space from ARIN..-- See the sponsorship thought below... 2. end user-- Wants to Multi-home Both ISP's charge for the /24 space monthly-- large enough that is becomes a challenge to a justify. Extensive maintenance for both ISPs to de-aggregate the block for multihoming. (ever watch the CIDR report and check the stats for prefix count increase?-- I watched one local ISP when I multihomed a customer on their IP space.. they jumped up to #6) (today this end user has a /28 from one provider and a /29 from another, PAT is rampant, route-map routing nightmare) 3. Local small co-op Has a 2 /25 from a single upstream-- each /25 is from different /24 (bottom of one and top of another) They have used 60-70%... and want to multi-home...As a power/gas/water co-op they still must get space from an upstream. Re-numbering will be a lengthy process.... how can we handle this? Last and my parting thought for the evening-- Sponsorship---And this is just a thought---- It seems to me that ISP's will give the /24 and be put through the ringer to allow for the de-aggregation of their IP space. So let's assume that ISP A, and ISP B serve customer Z. when ISP A gives a /24 to the customer, there is the ripple effect. ISP A must do a maintenance do de-ag their blocks. And coordinate this with UPSTREAM 1a thru 1c. who in conjunction may have to do the same to upstream 2a to 2X. and so on. If ISP A and/or ISP B sponsors customer Z and in effect adds comments to the customer's request for space, this would help EVERYONE in the internet community. In this case, the ARIN assigned PA /24 to the end user and it is added BGP filters for the upstreams and outbound from ISP A and B. Seems simpler.... But I know I have over simplified this...... Kind of like a pay it forward for ISPs.... To continue this thought--- Who would know the end user better than the ISP account manager that signed the customer up? So if the sponsorship is made part of the ARIN PA space request, then ISP gets a say in the assignment.-- IE-- simple checkbox-- DOES ISP A support the assignment of a PA /24 to CUSTOMER Z ? Can ISP A provide any documentation to assist or support the need for the /24 from ARIN? Comments? Thanks, Jim -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Friday, January 29, 2010 2:57 PM To: Owen DeLong Cc: Jim McBurnett; arin ppml Subject: Re: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title On Fri, Jan 29, 2010 at 2:13 PM, Owen DeLong wrote: > As I understand the NRPM, this proposal would enable customers who can justify > a need for 128 or more IP addresses and who are multihomed to get a /24. It would > not enable customers with, say, 8 addresses to get a /24 from ARIN, even though > they can get a /24 from one of their upstream providers. Hi Owen, The governing language is in NRPM 4.3.3 which reads: * A 25% immediate utilization rate, and * A 50% utilization rate within one year. So that's 64 addresses now and an additional 64 within one year. Except of course, nobody will check in a year to see if you used an additional 64 addresses. IMHO, 4.3.3 should probably be tightened up a bit as we approach free pool depletion, perhaps to something like "50% now and 75% in a year" or maybe just "50% now" since we probably aren't going to check in with end-users in a year anyway. Allowing assignments at the /24 level will help us do that since it would no longer have the effect of putting the minimum assignment size out of reach for small multihomed orgs in the "couple hundred people" category. > Thus, this policy only opens up ARIN PI /24s to a subset of those that can currently > get PA /24s, and, not everyone. ?While I would support a policy that had parity with > the PA /24 policy for direct assignments from ARIN, I think such a policy would be > far less likely to achieve community consensus at this time. Concur. Also, I'd like to see whether any problems (e.g. fraud) crop up at this proposal's level so that they can be corrected before attempting for full parity with NRPM 4.2.3.6. I don't anticipate any problems. ARIN's IPv4 process remains arcane enough to do a solid job keeping those without a genuine need at bay. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Fri Jan 29 19:53:44 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 16:53:44 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <1BC378592675E040B37CD2AE7C0A542A646951@OfficeExch2k7A.exchange.handynetworks.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> <1264805128.10926.1376.camel@fastlane.prognet.com> <1BC378592675E040B37CD2AE7C0A542A6451B7@OfficeExch2k7A.exchange.handynetworks.com> <4B6370D3.6080800@ipinc.net> <1BC378592675E040B37CD2AE7C0A542A646951@OfficeExch2k7A.exchange.handynetworks.com> Message-ID: <4B638318.3050601@ipinc.net> Jay Sudowski - Handy Networks LLC wrote: > Ted - > > PPML is melodrama/ideologue central, and the pair of comments > (Chris's and mine) hardly raise to the level of the actual melodrama > I have read on this list in the past several years. I just don't > appreciate the insinuation that because I, or anyone, wants to > protect their customer database from being pilfered from WHOIS It's not my experience that salesdroids dialing for dollars are very successful in plugging their wares to technical support people in charge of routers and suchlike. Ted is > actually simply hiding their bad apple customers from the larger > Internet. > > Eish ... > > -Jay > > -----Original Message----- From: Ted Mittelstaedt > [mailto:tedm at ipinc.net] Sent: Friday, January 29, 2010 4:36 PM To: > Jay Sudowski - Handy Networks LLC Cc: arin-ppml at arin.net Subject: Re: > [arin-ppml] Policy Proposal 95: Customer Confidentiality > > Jay, please knock off with the melodrama. > > Christopher was slamming Bill who is an OPPONENT of this policy. You > never heard of the enemy of my enemy is my friend, theory? > > The supporters of this proposal - who you count yourself in - have > won a little victory here. It is not necessary for you to roll > around in the mud too - at least, not yet ;-). > > Ted > > > Jay Sudowski - Handy Networks LLC wrote: >> Christopher - >> >> Those of us who support this petition and proposal do not have a >> business model that rely on hiding spammers and other nefarious >> actors. Your comment is insulting, and does nothing to further the >> discussion on this topic. >> >> -Jay >> >> >> -----Original Message----- From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Rogers >> Sent: Friday, January 29, 2010 3:45 PM To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy Proposal 95: Customer >> Confidentiality >> >> >> If your business model relies upon hiding spammers and other >> malcontents- then come up with a new model. >> >> Christopher Rogers AS11922 - Real Networks 2601 Elliott Ave >> Seattle, WA 98121 >> >> >> >> _______________________________________________ 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 tedm at ipinc.net Fri Jan 29 19:57:32 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 16:57:32 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <3c3e3fca1001291641o5d40541ehd100049457ed2e13@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <3c3e3fca1001291025h773ad512xf786552d72db14af@mail.gmail.com> <1264805128.10926.1376.camel@fastlane.prognet.com> <38dd4e411001291507q376d188aq26be74b8f798a02f@mail.gmail.com> <3c3e3fca1001291641o5d40541ehd100049457ed2e13@mail.gmail.com> Message-ID: <4B6383FC.1040400@ipinc.net> William Herrin wrote: > On Fri, Jan 29, 2010 at 6:07 PM, Joe Morgan wrote: >> If I was going to hide a spammer would I provide the actual swip >> information in the first place? > > Certainly. If you were clever about it, you'd SWIP it to look like a > bunch of entirely different residential customers. If you were subtle > about it, you could keep the antispam folks chasing their tails for > weeks before they started to smell a rat. > > > SWIP's point is to "keep honest people honest." You cook the books in > plain view and sooner or later someone will poke around and realize > something isn't right. So you don't cook the books. You pad your > requests a little bit, maybe you're a bit tardy deallocating departed > customers, but you don't make a big hoarding grab. And you can have > confidence that no one else will either because they have the same > hurdle you do. > > Hide enough information to make public audits impossible and you > defeat the whole point of SWIP. ARIN does not have the time or money to even audit REACHABILITY OF EMAIL ADDRESSES in WHOIS that is why they are using parliamentary delaying tricks on Section 3.6.1 of the NRPM. The idea that they would ever "privately" audit WHOIS is a joke. If you take away the ability to publically audit WHOIS then it will NEVER be audited. Ted From farmer at umn.edu Fri Jan 29 19:42:00 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 29 Jan 2010 18:42:00 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B636B12.6090603@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> Message-ID: <4B638058.7010500@umn.edu> Thanks, Ted that was a good summary. Ted Mittelstaedt wrote: > Naturally the AC will need to make the "official" determination > but it looks like we will be discussing this. Actually that is Staff's job, if the AC did that, it would be the fox guarding the chicken coop. The the Staff is much better at counting then us on the AC anyway, you know they have to count out each IP address right, just like a teller does at the bank. :) Talk about a barrier to IPv6 adoption. :) (only kidding) ARIN Staff is great!!! But, I believe most of the AC was watching, I know I was. > Marshall your arguments! :-) And yes you should do that, may I suggest everyone take a step back and take a breath first. So, a little more serious now; I would like to ask the community to think about how we all want this to work. Personally, I've been waiting for the petition process to kick in. I actually think it is a healthy thing and shows the process is working. But, we are setting precedent, this is the first petition for the new PDP, so lets try to make it good precedent and all do our part to make the system work. The first use of the Emergency PDP last year, wasn't the greatest experience for our community. I would hope we can make this first a much better experience for us all. And we all will play a part in making it a good experience. This got people charged up, but could you use a little of that energy and look that the other proposals, 101, 106, and 107. The AC need to finish up the text for these to go to staff and legal review, by EOB Monday. PP#101 has new language I sent out a couple days ago. PP#106 Scot and I are working on, and would hope we get some new text out. PP#107 I will be sending some more changes shortly based on feed back from the staff clarity review. Thanks and I hope to see many of you in Toronto. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From tedm at ipinc.net Fri Jan 29 20:00:20 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 17:00:20 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <05da01caa140$e111f5f0$a335e1d0$@net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net> <4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net> Message-ID: <4B6384A4.4040304@ipinc.net> Aaron Wendel wrote: >> You can support the idea but not the proposal. I definitely don't >> support the proposal. I am willing to look at the idea, however. If >> you can make a logical argument that the current policy as written >> makes it impossible for ISP's to exclude private individuals or >> residences in certain circumstances, I'd support a modification to >> current policy. > > I'm not sure I understand what you mean. Residential customers are already > covered under a separate policy allowing them to be deemed "private". My > proposal provides equal protection for hosted and collocated customers. > No it does not. Didn't you read your own proposal? It doesn't protect hosted and collocated customers AT ALL. It protects the _ISP's_ that sell services to those hosted and collocated customers. Those hosted and collocated customers are businesses that are out there paying good money to make themselves known to the world so they can sell websites and whatever else they do. Your idea of "protecting" them is to interfere with this process. >> You and the other supporters want to re-open discussion, because you >> clearly aren't willing to re-read the archives as to why this kind >> of proposal is generally a bad idea. Well, OK. I guess sometimes >> people don't want to read boring old archives and prefer the lively >> give and take of discussion. I think it's >> a diverting waste of time but since there's enough people that appear >> to need it, I'll do my duty as an opponent and try to show you of >> the error of your ways. > > And on this I will go so far as to say you have no idea what you're talking > about. I've read all the archives from 6 years ago. I don't agree with the > conclusion, feel that it is outdated and that ARIN membership and > participation has changed significantly enough that this topic deserves > revisiting. I've talked to many people who think this policy already exists > and when they are educated can't believe how stupid it is that it doesn't. > The previous proposal that failed is from 2004. It failed 20-7. 27 votes. > Almost that many people have weighed in on this topic just in the last 24 > hours. I feel it deserves to go to a vote. > So in other words, your going to slam the previous decision based on process and completely ignore the actual discussion itself - and all you have to offer is that ignorant people think it's stupid? There's a reason they are called "ignorant". > Hopefully, in the mean time, we can have a reasonable discussion on the > topic without people calling other people spammers, child molesters or > communists and come to a compromise that everyone can live with. > And your definition of "reasonable" is "agrees with my proposal" Ted > Aaron > > From tedm at ipinc.net Fri Jan 29 20:07:43 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 17:07:43 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B638058.7010500@umn.edu> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> Message-ID: <4B63865F.7070608@ipinc.net> David Farmer wrote: > Thanks, Ted that was a good summary. > > Ted Mittelstaedt wrote: >> Naturally the AC will need to make the "official" determination >> but it looks like we will be discussing this. > Actually that is Staff's job, if the AC did that, it would be the fox > guarding the chicken coop. The the Staff is much better at counting > then us on the AC anyway, you know they have to count out each IP > address right, just like a teller does at the bank. :) Talk about a > barrier to IPv6 adoption. :) (only kidding) ARIN Staff is great!!! > > But, I believe most of the AC was watching, I know I was. >> Marshall your arguments! :-) > And yes you should do that, may I suggest everyone take a step back and > take a breath first. > > So, a little more serious now; > > I would like to ask the community to think about how we all want this to > work. Personally, I've been waiting for the petition process to kick > in. I actually think it is a healthy thing and shows the process is > working. But, we are setting precedent, this is the first petition for > the new PDP, so lets try to make it good precedent and all do our part > to make the system work. The first use of the Emergency PDP last year, > wasn't the greatest experience for our community. I would hope we can > make this first a much better experience for us all. > > And we all will play a part in making it a good experience. > > This got people charged up, Of course it did. The success of the petition means one thing - that the AC made a bad decision. Nothing wrong with that we aren't all infallible, and that is why the petition process exists. My only observation on this is that I think if the AC had been more specific (and long) on the explanation of why it was dropped that people might not have supported the petition. They are not writing a UNIX man page, after all. Ted > but could you use a little of that energy > and look that the other proposals, 101, 106, and 107. The AC need to > finish up the text for these to go to staff and legal review, by EOB > Monday. > PP#101 has new language I sent out a couple days ago. > > PP#106 Scot and I are working on, and would hope we get some new text out. > > PP#107 I will be sending some more changes shortly based on feed back > from the staff clarity review. > > Thanks and I hope to see many of you in Toronto. > From gbonser at seven.com Fri Jan 29 20:13:47 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Jan 2010 17:13:47 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B6384A4.4040304@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net><4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net><4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net> <4B6384A4.4040304@ipinc.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F74E1@RWC-EX1.corp.seven.com> > No it does not. Didn't you read your own proposal? It doesn't protect > hosted and collocated customers AT ALL. It protects the _ISP's_ that > sell services to those hosted and collocated customers. Exactly the same take I have on it. Saying that it somehow "protects" the end user is intellectually dishonest and seems more like "spin" than anything else. It is designed to protect the ISP's customer list, just as they have said already in what debate has transpired. There is no other benefit to anyone else that I can discern from reading the proposal. From gbonser at seven.com Fri Jan 29 20:15:36 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Jan 2010 17:15:36 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <060b01caa144$66614820$3323d860$@net> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> <6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com> <060b01caa144$66614820$3323d860$@net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F74E2@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Aaron Wendel [mailto:aaron at wholesaleinternet.net] > Sent: Friday, January 29, 2010 4:37 PM > To: George Bonser > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > What is the proposal distinguished between "Hosted" customers and > "Downstream" customers? Meaning that if they have infrastructure in a > datacenter you control verses receive transit service from you in their > own > facility. What would you think of that? > > Aaron The only way such a proposal to have only the provider's contact info makes any sense is if the provider is basically the "operator" of the network and there is no other path to the internet except through that provider. Once there are multiple ways out and/or the customer manages the network themselves, they need to be listed. From aaron at wholesaleinternet.net Fri Jan 29 20:21:51 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 29 Jan 2010 19:21:51 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F74E2@RWC-EX1.corp.seven.com> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> <6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com> <060b01caa144$66614820$3323d860$@net> <5A6D953473350C4B9995546AFE9939EE081F74E2@RWC-EX1.corp.seven.com> Message-ID: <064a01caa14a$9a8f12c0$cfad3840$@net> Ok. How would you change the wording to reflect that? Aaron -----Original Message----- From: George Bonser [mailto:gbonser at seven.com] Sent: Friday, January 29, 2010 7:16 PM To: Aaron Wendel Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Policy Proposal 95: Customer Confidentiality > -----Original Message----- > From: Aaron Wendel [mailto:aaron at wholesaleinternet.net] > Sent: Friday, January 29, 2010 4:37 PM > To: George Bonser > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > What is the proposal distinguished between "Hosted" customers and > "Downstream" customers? Meaning that if they have infrastructure in a > datacenter you control verses receive transit service from you in their > own > facility. What would you think of that? > > Aaron The only way such a proposal to have only the provider's contact info makes any sense is if the provider is basically the "operator" of the network and there is no other path to the internet except through that provider. Once there are multiple ways out and/or the customer manages the network themselves, they need to be listed. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/29/10 13:35:00 From bill at herrin.us Fri Jan 29 20:21:46 2010 From: bill at herrin.us (William Herrin) Date: Fri, 29 Jan 2010 20:21:46 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: References: <4B58C4A5.2000406@arin.net> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> <62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com> <3c3e3fca1001291157s1c4b9c68rf4f78578ac0aa4d1@mail.gmail.com> Message-ID: <3c3e3fca1001291721j637e073bwb7c0865aad9282c9@mail.gmail.com> On Fri, Jan 29, 2010 at 7:46 PM, Jim McBurnett wrote: > 1. If an end user gets a /24 IP address space from an ISP via the /24 MH rule-- > ? ? ? ?Why such a big difference in PA from ARIN? > ? ? ? ?BUT does the ISP check usage? Hi Jim, As a thought experiment: if you buy a $20 Verizon residential DSL account, and ask Verizon to give you a /24 because you also have a Cox cable modem, what sort of response do you expect? Bear in mind that a /24 for multihoming means they have to reprogram their border routers not to reject packets originating from that /24. If you ask ARIN for a /24 justified because you have Internet contracts with Verizon and Cox Business Services, what sort of response do you expect? That's one reason why letting the ISP decide whether or not to give you a /24 suppresses abuse. > 2. If I am going to get a /24 to multi-home for an end user, they will use at least 64. > ? ? ? ? BUT do we have a formal definition of usage? ?See below. > 4. Usage-- > I have never seen a clear definition of usage. Usage is host count, network structure overhead and anything else you can convince the well educated application evaluator at ARIN to accept as legitimate. It's intentionally informal so that it doesn't accidentally exclude reasonable uses. > 3. Fraud-- > ? ? ? ?Please correct me if I am wrong here.. BUT isn't > there a requirement now for a C Level or VP?To put their > John Hancock on the request? ?For Fraud to be a reason > to vote this down is wrong. IMHO.?Attempts to make rules > to account for fraud can never include all the variables to > be worth the time. Process issues can encourage or discourage fraud. I personally think this proposal is neutral on the issue of fraud, but I can't agree that its inappropriate to consider a policy's potential impact on fraud. > 5. De-aggregation-- ?If I am an ISP today and I have a /16. >And I have to de-aggregate a block of say /19 to give a /24 for an end user.. > ? ? ? ?How much growth do I add to the global route table ? If he's multihomed, you announces two routes in the routing table. You announce the original /19 and you also propagate the customer's /24 announcement "cut out" from the /19. In the case of a /19 for most of your customers and an ARIN /24 for the one multihomed guy, you also announce two routes: Your /19 and you propagate the customer's /24 announcement. So it's a wash. Either way the same number of routes are carried in the DFZ. In neither case is the /24 aggregable with the /19 at any point in the DFZ although either one can be aggregated with a default route once you reach the DFZ border. However, the renumbering requirement in the proposal adds a kicker. You don't have to renumber out of an ISP /24 to add a second. So, when you have two ISP /24's, you have to announce two /24 cutouts of the ISP's /19. When it's time for a second ARIN /24 you're required to renumber into a /23. This /23 can be announced as just one route in addition to the ISP's /19. So at least in theory this proposal -reduces- the routing table load due to small multihomed organizations. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From aaron at wholesaleinternet.net Fri Jan 29 20:28:50 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 29 Jan 2010 19:28:50 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B6384A4.4040304@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net> <4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net> <4B6384A4.4040304@ipinc.net> Message-ID: <065001caa14b$9a626800$cf273800$@net> >No it does not. Didn't you read your own proposal? It doesn't protect >hosted and collocated customers AT ALL. It protects the _ISP's_ that >sell services to those hosted and collocated customers. You must be reading something different. My proposal is about obscuring the address, phone number and e-mail of a collocated or hosted customer to prevent poaching by competition. I can use the rational that it protects the ISPs customer list and I could also use the "it protects customer privacy" argument that obviously won 2004-7. >Those hosted and collocated customers are businesses that are out there >paying good money to make themselves known to the world so they can >sell websites and whatever else they do. Your idea of "protecting" them >is to interfere with this process. Not all of them. I have a customer, Action Photo. It's a photography studio run by two people. They colo a server with me and have a /29. I have to SWIP their information even though they are the last people that should be called if there's an issue and would just end up calling me anyway. >So in other words, your going to slam the previous decision based on >process and completely ignore the actual discussion itself - and all you >have to offer is that ignorant people think it's stupid? No. I'm going to change it. There's a process for that and it's the process I'm going to use. You insinuating that I am somehow trying to circumvent the system or shove it down people's throat by using my right to petition for a draft proposal shows your ignorance of the very system you proclaim to be supporting. >And your definition of "reasonable" is "agrees with my proposal" Are you serious because I'm starting to think you're just messing with me. I replied to a post from George Bonser asking how he would change it and one from YOU talking about compromise. Make a suggestion. Aaron From bicknell at ufp.org Fri Jan 29 20:35:10 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 Jan 2010 17:35:10 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <02c701caa054$b71df010$2559d030$@net> References: <02c701caa054$b71df010$2559d030$@net> Message-ID: <20100130013510.GA2300@ussenterprise.ufp.org> I supported the petition for this proposal. I did that not because I think this proposal is perfect, but because I think the issue is still important and relevant. Also, as I have already posted, I believe there is a new twist on it with respect to IPv6; which may not be discussed in this proposal but it can be a vehicle for this discussion. However, this issue is not new. Some of our newer members may not understand that. If you were not around for the following discussions, you may want to look in the Policy Proposal Archive on ARIN's web site, and or reach some back PPML archives.... 2001-7: Bulk ARIN WHOIS Data 2002-4: Bulk Copies of ARIN's WHOIS 2002-8: Privatizing POC Information 2003-1: Required Performance of Abuse Contact 2003-2: Network Abuse 2003-5: Distributed Information Server Use Requirements 2003-9: WHOIS Acceptable Use Policy (AUP) 2003-11: Purpose and scope of WHOIS directory 2003-16: POC Verification 2004-4: Purpose and scope of ARIN WHOIS directory 2004-6: Privacy of Reassignment Information 2004-7: Residential Customer Privacy 2005-2: Directory Services Overhaul 2006-1: Residential Customer Privacy 2006-6: Bulk WHOIS agreement expiration clarification 2008-1: SWIP support for smaller than /29 assignements 2008-7: WHOIS Integrity Policy Proposal If you want my take on the entire area; the vast majority of folks are unhappy with the current state of how SWIP/WHOIS/contact information is entered, used and distributed. However, even though perhaps 80% of the people are unhappy with the current system, no more than 20% of the people can agree on any "solution", and thus the status quo always wins. However I think the sheer number of proposals is proof that the status quo is not working for a lot of people. Sadly though, the discussion has already devolved into useless analogies, attacks, lack of understanding, lack of empathy, and down right cynicism. Everyone is sure there is some ulterior motive involved, to hide a spammer, make money, or game the system. Rather than thinking about Joe Average, everyone is talking about the one corner case that will always exist, no matter what system we have in place. Quite frankly, everyone involved needs to go back, read the archives of all of the proposals above, think hard about the principals they actually support, and post about those. Attacking each other, or coming up with wild scenarios to prove your point is well, a waste of everyones time and effort. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From aaron at wholesaleinternet.net Fri Jan 29 20:38:52 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 29 Jan 2010 19:38:52 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <20100130013510.GA2300@ussenterprise.ufp.org> References: <02c701caa054$b71df010$2559d030$@net> <20100130013510.GA2300@ussenterprise.ufp.org> Message-ID: <067e01caa14c$fb749b30$f25dd190$@net> Thanks Leo, I'm going to take the weekend to reread the proposals below and will refrain from posting again until next week. I hope everyone has a peaceful weekend. Aaron -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell Sent: Friday, January 29, 2010 7:35 PM To: ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality I supported the petition for this proposal. I did that not because I think this proposal is perfect, but because I think the issue is still important and relevant. Also, as I have already posted, I believe there is a new twist on it with respect to IPv6; which may not be discussed in this proposal but it can be a vehicle for this discussion. However, this issue is not new. Some of our newer members may not understand that. If you were not around for the following discussions, you may want to look in the Policy Proposal Archive on ARIN's web site, and or reach some back PPML archives.... 2001-7: Bulk ARIN WHOIS Data 2002-4: Bulk Copies of ARIN's WHOIS 2002-8: Privatizing POC Information 2003-1: Required Performance of Abuse Contact 2003-2: Network Abuse 2003-5: Distributed Information Server Use Requirements 2003-9: WHOIS Acceptable Use Policy (AUP) 2003-11: Purpose and scope of WHOIS directory 2003-16: POC Verification 2004-4: Purpose and scope of ARIN WHOIS directory 2004-6: Privacy of Reassignment Information 2004-7: Residential Customer Privacy 2005-2: Directory Services Overhaul 2006-1: Residential Customer Privacy 2006-6: Bulk WHOIS agreement expiration clarification 2008-1: SWIP support for smaller than /29 assignements 2008-7: WHOIS Integrity Policy Proposal If you want my take on the entire area; the vast majority of folks are unhappy with the current state of how SWIP/WHOIS/contact information is entered, used and distributed. However, even though perhaps 80% of the people are unhappy with the current system, no more than 20% of the people can agree on any "solution", and thus the status quo always wins. However I think the sheer number of proposals is proof that the status quo is not working for a lot of people. Sadly though, the discussion has already devolved into useless analogies, attacks, lack of understanding, lack of empathy, and down right cynicism. Everyone is sure there is some ulterior motive involved, to hide a spammer, make money, or game the system. Rather than thinking about Joe Average, everyone is talking about the one corner case that will always exist, no matter what system we have in place. Quite frankly, everyone involved needs to go back, read the archives of all of the proposals above, think hard about the principals they actually support, and post about those. Attacking each other, or coming up with wild scenarios to prove your point is well, a waste of everyones time and effort. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/29/10 13:35:00 From john.sweeting at twcable.com Fri Jan 29 20:41:04 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 29 Jan 2010 20:41:04 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive Message-ID: <6C245EFEC0ABBD4E8C810D9BAE4E269D3B396522@PRVPEXVS10.corp.twcable.com> Ted, A successful petition does not reflect at all on the AC. What it reflects is a split community with as much support for as against the proposal. In a case like this it would make sense that a petition would be successful. Aaron can now prepare to present this draft policy while the AC works on the other proposals that we have moved forwrd in the process. -john ++ ----- Original Message ----- From: arin-ppml-bounces at arin.net To: David Farmer Cc: John Curran ; arin-ppml at arin.net Sent: Fri Jan 29 20:07:43 2010 Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive David Farmer wrote: > Thanks, Ted that was a good summary. > > Ted Mittelstaedt wrote: >> Naturally the AC will need to make the "official" determination >> but it looks like we will be discussing this. > Actually that is Staff's job, if the AC did that, it would be the fox > guarding the chicken coop. The the Staff is much better at counting > then us on the AC anyway, you know they have to count out each IP > address right, just like a teller does at the bank. :) Talk about a > barrier to IPv6 adoption. :) (only kidding) ARIN Staff is great!!! > > But, I believe most of the AC was watching, I know I was. >> Marshall your arguments! :-) > And yes you should do that, may I suggest everyone take a step back and > take a breath first. > > So, a little more serious now; > > I would like to ask the community to think about how we all want this to > work. Personally, I've been waiting for the petition process to kick > in. I actually think it is a healthy thing and shows the process is > working. But, we are setting precedent, this is the first petition for > the new PDP, so lets try to make it good precedent and all do our part > to make the system work. The first use of the Emergency PDP last year, > wasn't the greatest experience for our community. I would hope we can > make this first a much better experience for us all. > > And we all will play a part in making it a good experience. > > This got people charged up, Of course it did. The success of the petition means one thing - that the AC made a bad decision. Nothing wrong with that we aren't all infallible, and that is why the petition process exists. My only observation on this is that I think if the AC had been more specific (and long) on the explanation of why it was dropped that people might not have supported the petition. They are not writing a UNIX man page, after all. Ted > but could you use a little of that energy > and look that the other proposals, 101, 106, and 107. The AC need to > finish up the text for these to go to staff and legal review, by EOB > Monday. > PP#101 has new language I sent out a couple days ago. > > PP#106 Scot and I are working on, and would hope we get some new text out. > > PP#107 I will be sending some more changes shortly based on feed back > from the staff clarity review. > > Thanks and I hope to see many of you in Toronto. > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From gbonser at seven.com Fri Jan 29 20:52:07 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Jan 2010 17:52:07 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: CustomerConfidentiality - Time Sensitive In-Reply-To: <065001caa14b$9a626800$cf273800$@net> References: <02c701caa054$b71df010$2559d030$@net><4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net><4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net><4B6384A4.4040304@ipinc.net> <065001caa14b$9a626800$cf273800$@net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F74E7@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Aaron Wendel > Sent: Friday, January 29, 2010 5:29 PM > To: 'Ted Mittelstaedt' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: > CustomerConfidentiality - Time Sensitive > My proposal is about > obscuring the > address, phone number and e-mail of a collocated or hosted customer to > prevent poaching by competition. I can use the rational that it > protects > the ISPs customer list and I could also use the "it protects customer > privacy" argument that obviously won 2004-7. Well, so I am a competitor combing through whois. I see some-odd-site.com is your customer but there is no address and phone number. So I either go to their contact page on their website or use directory assistance to look them up, and ask the person answering the phone to speak to the person in charge of their internet operations. So how are they or you "protected" by such a rule and how does it prevent someone from cold calling your customers. Companies advertize and try to make it the opposite of difficult to contact them. From Ed.Wrona at aeroflex.com Fri Jan 29 20:55:56 2010 From: Ed.Wrona at aeroflex.com (Wrona, Ed) Date: Fri, 29 Jan 2010 20:55:56 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: CustomerConfidentiality - Time Sensitive In-Reply-To: <065001caa14b$9a626800$cf273800$@net> References: <02c701caa054$b71df010$2559d030$@net><4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net><4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net><4B6384A4.4040304@ipinc.net> <065001caa14b$9a626800$cf273800$@net> Message-ID: <9044AC0DFE57D142B393E2E1684E94E054C00C@EVS1.aeroflex.corp> Aaron: You make a valid point with the Action Photo analogy, however IMHO, they and companies like them represent a small percentage of colo customers. In the vast majority of cases, customers are the only ones with administrative access to an offending machine, again my opinion. Other than shutting down their cross-connect, I am not quite sure what the network operator would do in the case of such a complaint. In either case, I have been reading this thread all day and I just do not understand the rationale. Since you have stated that: "My proposal is about obscuring the address, phone number and e-mail of a collocated or hosted customer to prevent poaching by competition." I may be way off base, however, from my perspective, I just don't see this happening. I have never once received a solicitation or cold call from any network provider looking to offer service based on one of our SWIP's (or not that I recall or know of). Further, how does hiding the address, phone number, and email prevent this "poaching" if it does exist ? If the name of the company is there, can't they do some extra work and make the solicitation anyway ? Ed Wrona Network Administrator Aeroflex, Inc. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Aaron Wendel Sent: Friday, January 29, 2010 8:29 PM To: 'Ted Mittelstaedt' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: CustomerConfidentiality - Time Sensitive >No it does not. Didn't you read your own proposal? It doesn't protect >hosted and collocated customers AT ALL. It protects the _ISP's_ that >sell services to those hosted and collocated customers. You must be reading something different. My proposal is about obscuring the address, phone number and e-mail of a collocated or hosted customer to prevent poaching by competition. I can use the rational that it protects the ISPs customer list and I could also use the "it protects customer privacy" argument that obviously won 2004-7. >Those hosted and collocated customers are businesses that are out there >paying good money to make themselves known to the world so they can >sell websites and whatever else they do. Your idea of "protecting" them >is to interfere with this process. Not all of them. I have a customer, Action Photo. It's a photography studio run by two people. They colo a server with me and have a /29. I have to SWIP their information even though they are the last people that should be called if there's an issue and would just end up calling me anyway. >So in other words, your going to slam the previous decision based on >process and completely ignore the actual discussion itself - and all you >have to offer is that ignorant people think it's stupid? No. I'm going to change it. There's a process for that and it's the process I'm going to use. You insinuating that I am somehow trying to circumvent the system or shove it down people's throat by using my right to petition for a draft proposal shows your ignorance of the very system you proclaim to be supporting. >And your definition of "reasonable" is "agrees with my proposal" Are you serious because I'm starting to think you're just messing with me. I replied to a post from George Bonser asking how he would change it and one from YOU talking about compromise. Make a suggestion. Aaron _______________________________________________ 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. Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged, company confidential and/or exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail or collect telephone call and delete or destroy all copies of this e-mail message, any physical copies made of this e-mail message and/or any file attachment(s). From jim at tgasolutions.com Fri Jan 29 21:22:20 2010 From: jim at tgasolutions.com (Jim McBurnett) Date: Fri, 29 Jan 2010 21:22:20 -0500 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <3c3e3fca1001291721j637e073bwb7c0865aad9282c9@mail.gmail.com> References: <4B58C4A5.2000406@arin.net> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> <62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com> <3c3e3fca1001291157s1c4b9c68rf4f78578ac0aa4d1@mail.gmail.com> <3c3e3fca1001291721j637e073bwb7c0865aad9282c9@mail.gmail.com> Message-ID: >>That's one reason why letting the ISP decide whether or not to give >>you a /24 suppresses abuse. Bill, This one item is a perfect example of the sponsorship idea I put at the end of my last post.. Checkbox-- ISP A and ISP B-- Would you assign a /24 to this end user? Fill in the blank: (why or why not) The ISP's retain the right to have a comment on the assignment.. Would that calm the concern about abuse? Policy could read: Upon submission for an ARIN Assigned PA /24, ARIN will contact both upstream ISP's via email utilizing the POC for that BGP ASN. If ISP endorses the request, the request is advanced for further ARIN consideration. If ISP does not respond within 5 business days, endorsement is considered to be implied. If ISP does not respond favorably, requesting organization is referred to that ISP and the merits of the ISP endorsement is considered by ARIN. Where ARIN may or may not advance the request based on the standing policies at the time. ISP may rescind or modify their endorsement in a timeline to be published in the endorsement requesting email from ARIN. That timeline should not exceed a period of 10 business days. Thoughts? Thanks, Jim From tedm at ipinc.net Fri Jan 29 21:51:30 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Jan 2010 18:51:30 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <20100130013510.GA2300@ussenterprise.ufp.org> References: <02c701caa054$b71df010$2559d030$@net> <20100130013510.GA2300@ussenterprise.ufp.org> Message-ID: <4B639EB2.1080801@ipinc.net> Leo Bicknell wrote: > I supported the petition for this proposal. I did that not because > I think this proposal is perfect, but because I think the issue is > still important and relevant. Also, as I have already posted, I > believe there is a new twist on it with respect to IPv6; which may > not be discussed in this proposal but it can be a vehicle for this > discussion. > > However, this issue is not new. Some of our newer members may not > understand that. If you were not around for the following discussions, > you may want to look in the Policy Proposal Archive on ARIN's web > site, and or reach some back PPML archives.... > > 2001-7: Bulk ARIN WHOIS Data > 2002-4: Bulk Copies of ARIN's WHOIS > 2002-8: Privatizing POC Information > 2003-1: Required Performance of Abuse Contact > 2003-2: Network Abuse > 2003-5: Distributed Information Server Use Requirements > 2003-9: WHOIS Acceptable Use Policy (AUP) > 2003-11: Purpose and scope of WHOIS directory > 2003-16: POC Verification > 2004-4: Purpose and scope of ARIN WHOIS directory > 2004-6: Privacy of Reassignment Information > 2004-7: Residential Customer Privacy > 2005-2: Directory Services Overhaul > 2006-1: Residential Customer Privacy > 2006-6: Bulk WHOIS agreement expiration clarification > 2008-1: SWIP support for smaller than /29 assignements > 2008-7: WHOIS Integrity Policy Proposal > > If you want my take on the entire area; the vast majority of folks > are unhappy with the current state of how SWIP/WHOIS/contact > information is entered, used and distributed. I have to disagree with that. Everyone on this list has not posted regarding this issue. The people posting are the ones who are unhappy and the ones (like myself) who think their objections are unwarranted. But that is not the "majority of folks" It MIGHT be the "majority of posters" but the posters on both sides are a minority. Also a lot of people are unhappy with how the information is entered because they don't like the SWIP system and want to replace it with some webinterface thing, they are not objecting the the actual principle of making the data available. Other RIR's don't seem to have a problem with this data being available and I frankly think that the reason this topic generates attention on this list is that because the list is heavy with people from North America where so much of the Internet connectivity is provided privately by corporations. In the US there is this cultural mythos surrounding the perceived "business underdog". People root for the small guy against his large competitors, Microsoft for example was the darling of the hobby market when it was slugging it out with IBM - then when Microsoft got big everyone who loved it turned their back on it and now they love Apple, (and are willing to pay 6 times for a computer for the privilege but that's a different story). This despite the fact that the little guy in some cases is providing an inferior product against the big guy. (ie: the ipod shuffle vs the Sony MP3 walkman) The people pushing these "cover your IPs" type proposals like to frame it as David vs Goliath, due to this mythos, and it always gets good press, the small struggling ISP being poached by the giant lumbering ISP who sets their sales dogs to digging into WHOIS. The reality is that there isn't significant customer loss from poaching WHOIS from a business that is doing a good job and keeping it's customers happy. Speaking from sales experience, trying to poach customers from a WHOIS list is really, really dumb. A good salesman is going to define a territory of customers, figure out how to serve them, then go after them. A territory is commonality between customers. Some companies use geography as a criteria, some use type of business. Some use connections and their customer territory looks senseless from an outside observer until you find out that all their customers golf at the same course as the salesman. NO territory I ever heard of a salesman using ever mapped neatly onto TCP/IP ranges. ISPs do not customarily group all their medical customers into the same IP range, or all their construction customers, or all their customers who run webservers. You could get a better lead list from pointing a blunderbuss at the phone book and pulling the trigger and going after anything still readable than by pulling WHOIS data. At least, with the phone book method, they would all live in the same area. > However, even though > perhaps 80% of the people are unhappy with the current system, no > more than 20% of the people can agree on any "solution", and thus > the status quo always wins. > > However I think the sheer number of proposals is proof that the > status quo is not working for a lot of people. > The sheer number of proposals is frankly because the opponents of the status quo are arguing on principle, as are the supporters of the status quo. It is an argument that YOU, Leo, aren't going to solve, nor am I. It is like the Abortion argument in the US, it's a fight based on principles on both sides, and it isn't going to end, ever, no matter what the law is written to say. If the status quo was that ARIN covered everything then there would be just as many proposals to OPEN the database. > Sadly though, the discussion has already devolved into useless > analogies, attacks, lack of understanding, lack of empathy, and > down right cynicism. Everyone is sure there is some ulterior motive > involved, to hide a spammer, make money, or game the system. Rather > than thinking about Joe Average, everyone is talking about the one > corner case that will always exist, no matter what system we have > in place. > I am sorry you are so cynical yourself to say that but that just isn't true. As someone else posted this topic is fundamentally an argument of the Good of the Many outweighing the Good of the Few, or the One. (for those Trekkies out there) Yes, for some "corner cases" it might be beneficial to privatize their SWIPS, if for no other reason than they lack the creativity of coming up with baloney names for SWIP entries (ie: Universal Exports, Binford Tools, and the like) But the community would suffer, as there is currently NO procedure for routine audits by the RIR of the SWIP data, nor is there ever likely to be, and almost certainly nobody on this list would be willing to see their fees increase to pay for one. IPv6 does not change this because the issue here is reachability of the other guy who is spamming/attacking/whatever to you vs reachability of the other guy so you can waste your time trying to poach him. History is replete with examples of this kind of argument, over a great many topics, and there's no shortage of them today. People get emotional and come up with wild scenarios to prove their point because this is how these arguments work. And usually there is not much movement from either side - which is why the AC tried dropping this proposal in the first place. I will close with one last point, and that is the Internet got to where it is today with the system it has now. That is probably the most compelling argument that openness in WHOIS was the right choice in the beginning, as it has WORKED. Ted From joe at joesdatacenter.com Fri Jan 29 22:36:23 2010 From: joe at joesdatacenter.com (Joe Morgan) Date: Fri, 29 Jan 2010 21:36:23 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <4B639EB2.1080801@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <20100130013510.GA2300@ussenterprise.ufp.org> <4B639EB2.1080801@ipinc.net> Message-ID: <38dd4e411001291936i42584c57ne0e1e81088a4e9bd@mail.gmail.com> Quoting TED "I will close with one last point, and that is the Internet got to where it is today with the system it has now. That is probably the most compelling argument that openness in WHOIS was the right choice in the beginning, as it has WORKED." I think this just shows how closed minded you are. I have never heard any intelligent argument that states that just because something worked it was the best way. I happen to think there is probably always a better way which is exactly why we have the processes in place that we do to change things. It is even possible that the internet would be much better than it is today had some changes been made. Does that mean I am criticizing the people who worked on it before and the advances they made? No not at all. I am simply trying to say that just because it worked and maybe worked in a good way does not mean it was the best way or that it is the best way for right now. On Fri, Jan 29, 2010 at 8:51 PM, Ted Mittelstaedt wrote: > Leo Bicknell wrote: >> >> I supported the petition for this proposal. ?I did that not because >> I think this proposal is perfect, but because I think the issue is >> still important and relevant. ?Also, as I have already posted, I >> believe there is a new twist on it with respect to IPv6; which may >> not be discussed in this proposal but it can be a vehicle for this >> discussion. >> >> However, this issue is not new. ?Some of our newer members may not >> understand that. ?If you were not around for the following discussions, >> you may want to look in the Policy Proposal Archive on ARIN's web >> site, and or reach some back PPML archives.... >> >> 2001-7: Bulk ARIN WHOIS Data >> 2002-4: Bulk Copies of ARIN's WHOIS >> 2002-8: Privatizing POC Information >> 2003-1: Required Performance of Abuse Contact >> 2003-2: Network Abuse >> 2003-5: Distributed Information Server Use Requirements >> 2003-9: WHOIS Acceptable Use Policy (AUP) >> 2003-11: Purpose and scope of WHOIS directory >> 2003-16: POC Verification >> 2004-4: Purpose and scope of ARIN WHOIS directory >> 2004-6: Privacy of Reassignment Information >> 2004-7: Residential Customer Privacy >> 2005-2: Directory Services Overhaul >> 2006-1: Residential Customer Privacy >> 2006-6: Bulk WHOIS agreement expiration clarification >> 2008-1: SWIP support for smaller than /29 assignements >> 2008-7: WHOIS Integrity Policy Proposal >> >> If you want my take on the entire area; the vast majority of folks >> are unhappy with the current state of how SWIP/WHOIS/contact >> information is entered, used and distributed. > > I have to disagree with that. ?Everyone on this list has not posted > regarding this issue. ?The people posting are the ones who are > unhappy and the ones (like myself) who think their objections are > unwarranted. ?But that is not the "majority of folks" ?It MIGHT be > the "majority of posters" but the posters on both sides are a > minority. > > Also a lot of people are unhappy with how the information is entered > because they don't like the SWIP system and want to replace it with > some webinterface thing, they are not objecting the the actual principle > of making the data available. > > Other RIR's don't seem to have a problem with this data being available > and I frankly think that the reason this topic generates attention > on this list is that because the list is heavy with people from North > America where so much of the Internet connectivity is provided privately by > corporations. > > In the US there is this cultural mythos surrounding the perceived > "business underdog". ?People root for the small guy against his large > competitors, Microsoft for example was the darling of the hobby market > when it was slugging it out with IBM - then when Microsoft got big > everyone who loved it turned their back on it and now they love Apple, > (and are willing to pay 6 times for a computer for the privilege but > that's a different story). ?This despite the fact that the little guy > in some cases is providing an inferior product against the big guy. > (ie: the ipod shuffle vs the Sony MP3 walkman) > > The people pushing these "cover your IPs" type proposals like to frame > it as David vs Goliath, due to this mythos, and it always gets good > press, the small struggling ISP being poached by the giant lumbering > ISP who sets their sales dogs to digging into WHOIS. > > The reality is that there isn't significant customer loss from poaching > WHOIS from a business that is doing a good job and keeping it's customers > happy. ?Speaking from sales experience, trying to poach customers from a > WHOIS list is really, really dumb. ?A good salesman is > going to define a territory of customers, figure out how to serve > them, then go after them. ?A territory is commonality between > customers. ?Some companies use geography as a criteria, some > use type of business. Some use connections and their customer > territory looks senseless from an outside observer until you > find out that all their customers golf at the same course as the > salesman. ?NO territory I ever heard of a salesman using ever > mapped neatly onto TCP/IP ranges. ?ISPs do not customarily > group all their medical customers into the same IP range, or > all their construction customers, or all their customers who > run webservers. ?You could get a better lead > list from pointing a blunderbuss at the phone book and pulling > the trigger and going after anything still readable than by > pulling WHOIS data. ?At least, with the phone book method, they > would all live in the same area. > >> ?However, even though >> >> perhaps 80% of the people are unhappy with the current system, no >> more than 20% of the people can agree on any "solution", and thus >> the status quo always wins. >> >> However I think the sheer number of proposals is proof that the >> status quo is not working for a lot of people. >> > > The sheer number of proposals is frankly because the opponents > of the status quo are arguing on principle, as are the supporters > of the status quo. ?It is an argument that YOU, Leo, aren't going to > solve, nor am I. ?It is like the Abortion argument in the US, it's > a fight based on principles on both sides, and it isn't going to > end, ever, no matter what the law is written to say. > > If the status quo was that ARIN covered everything then there > would be just as many proposals to OPEN the database. > >> Sadly though, the discussion has already devolved into useless >> analogies, attacks, lack of understanding, lack of empathy, and >> down right cynicism. ?Everyone is sure there is some ulterior motive >> involved, to hide a spammer, make money, or game the system. ?Rather >> than thinking about Joe Average, everyone is talking about the one >> corner case that will always exist, no matter what system we have >> in place. >> > > I am sorry you are so cynical yourself to say that but that > just isn't true. > > As someone else posted this topic is fundamentally an argument > of the Good of the Many outweighing the Good of the Few, or > the One. ?(for those Trekkies out there) ?Yes, for some > "corner cases" it might be beneficial to privatize their > SWIPS, if for no other reason than they lack the creativity of > coming up with baloney names for SWIP entries (ie: Universal > Exports, Binford Tools, and the like) ?But the community would > suffer, as there is currently NO procedure for routine audits > by the RIR of the SWIP data, nor is there ever likely to be, > and almost certainly nobody on this list would be willing to > see their fees increase to pay for one. ?IPv6 does not change > this because the issue here is reachability of the other guy who > is spamming/attacking/whatever to you vs reachability of the > other guy so you can waste your time trying to poach him. > > History is replete with examples of this kind of argument, over > a great many topics, and there's no shortage of them today. > People get emotional and come up with wild scenarios to prove > their point because this is how these arguments work. ?And usually > there is not much movement from either side - which is why the > AC tried dropping this proposal in the first place. > > I will close with one last point, and that is the Internet got > to where it is today with the system it has now. ?That is probably > the most compelling argument that openness in WHOIS was the > right choice in the beginning, as it has WORKED. > > Ted > > _______________________________________________ > 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. > -- Thank You, Joe Morgan Joe's Datacenter, LLC http://joesdatacenter.com From jcurran at arin.net Fri Jan 29 23:42:18 2010 From: jcurran at arin.net (John Curran) Date: Fri, 29 Jan 2010 23:42:18 -0500 Subject: [arin-ppml] Conduct discussions on PPML with respect for all participants In-Reply-To: <38dd4e411001291936i42584c57ne0e1e81088a4e9bd@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <20100130013510.GA2300@ussenterprise.ufp.org> <4B639EB2.1080801@ipinc.net> <38dd4e411001291936i42584c57ne0e1e81088a4e9bd@mail.gmail.com> Message-ID: Folks - Please keep postings focused on the issues surrounding Internet number resource policy, and with respect to all participants in the discussion. This will help keep the discussion relevant and informative for all. Thank you, /John John Curran President and CEO ARIN On Jan 29, 2010, at 10:36 PM, Joe Morgan wrote: > Quoting TED > > "I will close with one last point, and that is the Internet got > to where it is today with the system it has now. That is probably > the most compelling argument that openness in WHOIS was the > right choice in the beginning, as it has WORKED." > > I think this just shows how closed minded you are. I have never heard > any intelligent argument that states that just because something > worked it was the best way. I happen to think there is probably always > a better way which is exactly why we have the processes in place that > we do to change things. It is even possible that the internet would be > much better than it is today had some changes been made. Does that > mean I am criticizing the people who worked on it before and the > advances they made? No not at all. I am simply trying to say that just > because it worked and maybe worked in a good way does not mean it was > the best way or that it is the best way for right now. > > On Fri, Jan 29, 2010 at 8:51 PM, Ted Mittelstaedt wrote: >> Leo Bicknell wrote: >>> >>> I supported the petition for this proposal. I did that not because >>> I think this proposal is perfect, but because I think the issue is >>> still important and relevant. Also, as I have already posted, I >>> believe there is a new twist on it with respect to IPv6; which may >>> not be discussed in this proposal but it can be a vehicle for this >>> discussion. >>> >>> However, this issue is not new. Some of our newer members may not >>> understand that. If you were not around for the following discussions, >>> you may want to look in the Policy Proposal Archive on ARIN's web >>> site, and or reach some back PPML archives.... >>> >>> 2001-7: Bulk ARIN WHOIS Data >>> 2002-4: Bulk Copies of ARIN's WHOIS >>> 2002-8: Privatizing POC Information >>> 2003-1: Required Performance of Abuse Contact >>> 2003-2: Network Abuse >>> 2003-5: Distributed Information Server Use Requirements >>> 2003-9: WHOIS Acceptable Use Policy (AUP) >>> 2003-11: Purpose and scope of WHOIS directory >>> 2003-16: POC Verification >>> 2004-4: Purpose and scope of ARIN WHOIS directory >>> 2004-6: Privacy of Reassignment Information >>> 2004-7: Residential Customer Privacy >>> 2005-2: Directory Services Overhaul >>> 2006-1: Residential Customer Privacy >>> 2006-6: Bulk WHOIS agreement expiration clarification >>> 2008-1: SWIP support for smaller than /29 assignements >>> 2008-7: WHOIS Integrity Policy Proposal >>> >>> If you want my take on the entire area; the vast majority of folks >>> are unhappy with the current state of how SWIP/WHOIS/contact >>> information is entered, used and distributed. >> >> I have to disagree with that. Everyone on this list has not posted >> regarding this issue. The people posting are the ones who are >> unhappy and the ones (like myself) who think their objections are >> unwarranted. But that is not the "majority of folks" It MIGHT be >> the "majority of posters" but the posters on both sides are a >> minority. >> >> Also a lot of people are unhappy with how the information is entered >> because they don't like the SWIP system and want to replace it with >> some webinterface thing, they are not objecting the the actual principle >> of making the data available. >> >> Other RIR's don't seem to have a problem with this data being available >> and I frankly think that the reason this topic generates attention >> on this list is that because the list is heavy with people from North >> America where so much of the Internet connectivity is provided privately by >> corporations. >> >> In the US there is this cultural mythos surrounding the perceived >> "business underdog". People root for the small guy against his large >> competitors, Microsoft for example was the darling of the hobby market >> when it was slugging it out with IBM - then when Microsoft got big >> everyone who loved it turned their back on it and now they love Apple, >> (and are willing to pay 6 times for a computer for the privilege but >> that's a different story). This despite the fact that the little guy >> in some cases is providing an inferior product against the big guy. >> (ie: the ipod shuffle vs the Sony MP3 walkman) >> >> The people pushing these "cover your IPs" type proposals like to frame >> it as David vs Goliath, due to this mythos, and it always gets good >> press, the small struggling ISP being poached by the giant lumbering >> ISP who sets their sales dogs to digging into WHOIS. >> >> The reality is that there isn't significant customer loss from poaching >> WHOIS from a business that is doing a good job and keeping it's customers >> happy. Speaking from sales experience, trying to poach customers from a >> WHOIS list is really, really dumb. A good salesman is >> going to define a territory of customers, figure out how to serve >> them, then go after them. A territory is commonality between >> customers. Some companies use geography as a criteria, some >> use type of business. Some use connections and their customer >> territory looks senseless from an outside observer until you >> find out that all their customers golf at the same course as the >> salesman. NO territory I ever heard of a salesman using ever >> mapped neatly onto TCP/IP ranges. ISPs do not customarily >> group all their medical customers into the same IP range, or >> all their construction customers, or all their customers who >> run webservers. You could get a better lead >> list from pointing a blunderbuss at the phone book and pulling >> the trigger and going after anything still readable than by >> pulling WHOIS data. At least, with the phone book method, they >> would all live in the same area. >> >>> However, even though >>> >>> perhaps 80% of the people are unhappy with the current system, no >>> more than 20% of the people can agree on any "solution", and thus >>> the status quo always wins. >>> >>> However I think the sheer number of proposals is proof that the >>> status quo is not working for a lot of people. >>> >> >> The sheer number of proposals is frankly because the opponents >> of the status quo are arguing on principle, as are the supporters >> of the status quo. It is an argument that YOU, Leo, aren't going to >> solve, nor am I. It is like the Abortion argument in the US, it's >> a fight based on principles on both sides, and it isn't going to >> end, ever, no matter what the law is written to say. >> >> If the status quo was that ARIN covered everything then there >> would be just as many proposals to OPEN the database. >> >>> Sadly though, the discussion has already devolved into useless >>> analogies, attacks, lack of understanding, lack of empathy, and >>> down right cynicism. Everyone is sure there is some ulterior motive >>> involved, to hide a spammer, make money, or game the system. Rather >>> than thinking about Joe Average, everyone is talking about the one >>> corner case that will always exist, no matter what system we have >>> in place. >>> >> >> I am sorry you are so cynical yourself to say that but that >> just isn't true. >> >> As someone else posted this topic is fundamentally an argument >> of the Good of the Many outweighing the Good of the Few, or >> the One. (for those Trekkies out there) Yes, for some >> "corner cases" it might be beneficial to privatize their >> SWIPS, if for no other reason than they lack the creativity of >> coming up with baloney names for SWIP entries (ie: Universal >> Exports, Binford Tools, and the like) But the community would >> suffer, as there is currently NO procedure for routine audits >> by the RIR of the SWIP data, nor is there ever likely to be, >> and almost certainly nobody on this list would be willing to >> see their fees increase to pay for one. IPv6 does not change >> this because the issue here is reachability of the other guy who >> is spamming/attacking/whatever to you vs reachability of the >> other guy so you can waste your time trying to poach him. >> >> History is replete with examples of this kind of argument, over >> a great many topics, and there's no shortage of them today. >> People get emotional and come up with wild scenarios to prove >> their point because this is how these arguments work. And usually >> there is not much movement from either side - which is why the >> AC tried dropping this proposal in the first place. >> >> I will close with one last point, and that is the Internet got >> to where it is today with the system it has now. That is probably >> the most compelling argument that openness in WHOIS was the >> right choice in the beginning, as it has WORKED. >> >> Ted >> >> _______________________________________________ >> 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. >> > > > > -- > Thank You, > Joe Morgan > Joe's Datacenter, LLC > http://joesdatacenter.com > _______________________________________________ > 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 Sat Jan 30 00:54:18 2010 From: bill at herrin.us (William Herrin) Date: Sat, 30 Jan 2010 00:54:18 -0500 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <02c701caa054$b71df010$2559d030$@net> References: <02c701caa054$b71df010$2559d030$@net> Message-ID: <3c3e3fca1001292154v5091e371od56bbaa728f0091a@mail.gmail.com> On Thu, Jan 28, 2010 at 3:01 PM, Aaron Wendel wrote: > Customer contact lists are one of the most proprietary and confidential > pieces of information in any business. ?The requirements for ISPs to > publish those lists via SWIP or RWHOIS runs contrary to good business > practices and invites competitors and others to solicit both individuals > and companies receiving reassignments and sub allocations from upstream > providers. ARIN's acceptable use policy for whois data is: "The ARIN WHOIS data is for Internet operational or technical research purposes pertaining to Internet operations only. It may not be used for advertising, direct marketing, marketing research, or similar purposes. Use of ARIN WHOIS data for these activities is explicitly forbidden. ARIN requests to be notified of any such activities or suspicions thereof." Has anyone -ever- notified ARIN that one of its ISP members solicited a contact found via whois? What action did ARIN take? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sat Jan 30 01:44:34 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 30 Jan 2010 00:44:34 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <3c3e3fca1001292154v5091e371od56bbaa728f0091a@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <3c3e3fca1001292154v5091e371od56bbaa728f0091a@mail.gmail.com> Message-ID: <6eb799ab1001292244t6bde8bc0i569fe397e7efd7d2@mail.gmail.com> On Fri, Jan 29, 2010 at 11:54 PM, William Herrin wrote: > > Has anyone -ever- notified ARIN that one of its ISP members solicited > a contact found via whois? What action did ARIN take? well.. https://www.arin.net/contact_us.html Does not list any contact detail for WHOIS abuse reports. And https://www.arin.net/whois_tou.html The URL listed when you perform a WHOIS query, does not say anything about that. If ARIN is serious about wishing to be notified of suspected violations of the WHOIS policy, some means to receive that notification should be listed.. Including actual instructions or guidance as to the preferred method of notifying ARIN. -- -J From farmer at umn.edu Sat Jan 30 09:45:32 2010 From: farmer at umn.edu (David Farmer) Date: Sat, 30 Jan 2010 08:45:32 -0600 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <6eb799ab1001292244t6bde8bc0i569fe397e7efd7d2@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <3c3e3fca1001292154v5091e371od56bbaa728f0091a@mail.gmail.com> <6eb799ab1001292244t6bde8bc0i569fe397e7efd7d2@mail.gmail.com> Message-ID: <4B64460C.50904@umn.edu> James Hess wrote: > On Fri, Jan 29, 2010 at 11:54 PM, William Herrin wrote: >> Has anyone -ever- notified ARIN that one of its ISP members solicited >> a contact found via whois? What action did ARIN take? > > well.. > https://www.arin.net/contact_us.html > > Does not list any contact detail for WHOIS abuse reports. > And https://www.arin.net/whois_tou.html > The URL listed when you perform a WHOIS query, does not say > anything about that. > > If ARIN is serious about wishing to be notified of suspected > violations of the WHOIS policy, some means to receive that > notification should be listed.. > > Including actual instructions or guidance as to the preferred method > of notifying ARIN. OK, I think your criticisms might be slightly valid hear, there is nothing explicitly telling you where to send complaints of this kind. But from; https://www.arin.net/contact_us.html listed under hostmaster at arin.net * Registration Services questions (e.g. requests for number resources and other services, SWIP, reports of bad POCs, transfers, etc.) * Where to find Registration Services information on the website * Submission of all templates (except reassignments and reallocations) * Ticket status information * DNS questions * Requests for database reports * Network abuse issues and spam * ARIN policy questions * WHOIS questions * Revocation questions * Country code questions * Statistics questions * Routing Registry questions * General questions about ARIN's services So while "WHOIS terms of use violations" is not listed there, I do see "Network abuse issues and spam", "ARIN policy questions", and "WHOIS questions" that I think are at least related. Finally, there is a qualifying default route "General questions about ARIN's services" Given this list, I'll bet if you were to send such a report to hostmaster at arin.net that someone would take it seriously. Finally, if you feel this isn't sufficient you could make a suggestion here: https://www.arin.net/participate/acsp/index.html That "WHOIS terms of use violations" be explicitly listed on the contact us page, and I'll bet beer that it will get done. At the very least you would get an official response from ARIN Staff. Given the existence of the ACSP, making suggestion on PPML of this nature are mostly rhetorical. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From rudi.daniel at gmail.com Sat Jan 30 10:32:34 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sat, 30 Jan 2010 11:32:34 -0400 Subject: [arin-ppml] Petition Underway - Policy Proposal 95 Message-ID: <8aeeaff61001300732y73db3ff5mf6f45ea19d0dd5ca@mail.gmail.com> I would like to know if all the stated opinions relate more to an ipv4 world than ipv6, and as Leo touched on it, does ipv6 add a significant twist to the argument? RD > Message: 1 > Date: Fri, 29 Jan 2010 17:52:07 -0800 > From: "George Bonser" > To: "Aaron Wendel" , "Ted Mittelstaedt" > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: > CustomerConfidentiality - Time Sensitive > Message-ID: > <5A6D953473350C4B9995546AFE9939EE081F74E7 at RWC-EX1.corp.seven.com> > Content-Type: text/plain; charset="us-ascii" > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > Behalf Of Aaron Wendel > > Sent: Friday, January 29, 2010 5:29 PM > > To: 'Ted Mittelstaedt' > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: > > CustomerConfidentiality - Time Sensitive > > > > My proposal is about > > obscuring the > > address, phone number and e-mail of a collocated or hosted customer to > > prevent poaching by competition. I can use the rational that it > > protects > > the ISPs customer list and I could also use the "it protects customer > > privacy" argument that obviously won 2004-7. > > Well, so I am a competitor combing through whois. I see > some-odd-site.com is your customer but there is no address and phone > number. So I either go to their contact page on their website or use > directory assistance to look them up, and ask the person answering the > phone to speak to the person in charge of their internet operations. So > how are they or you "protected" by such a rule and how does it prevent > someone from cold calling your customers. > > Companies advertize and try to make it the opposite of difficult to > contact them. > > > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Jan 2010 20:55:56 -0500 > From: "Wrona, Ed" > To: "Aaron Wendel" , "Ted Mittelstaedt" > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: > CustomerConfidentiality - Time Sensitive > Message-ID: > <9044AC0DFE57D142B393E2E1684E94E054C00C at EVS1.aeroflex.corp> > Content-Type: text/plain; charset="us-ascii" > > Aaron: > > You make a valid point with the Action Photo analogy, however > IMHO, they and companies like them represent a small percentage of colo > customers. In the vast majority of cases, customers are the only ones > with administrative access to an offending machine, again my opinion. > Other than shutting down their cross-connect, I am not quite sure what > the network operator would do in the case of such a complaint. > > In either case, I have been reading this thread all day and I > just do not understand the rationale. Since you have stated that: > > "My proposal is about obscuring the > address, phone number and e-mail of a collocated or hosted customer to > prevent poaching by competition." > > I may be way off base, however, from my perspective, I just > don't see this happening. I have never once received a solicitation or > cold call from any network provider looking to offer service based on > one of our SWIP's (or not that I recall or know of). > > Further, how does hiding the address, phone number, and email > prevent this "poaching" if it does exist ? If the name of the company > is there, can't they do some extra work and make the solicitation anyway > ? > > > Ed Wrona > Network Administrator > Aeroflex, Inc. > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Aaron Wendel > Sent: Friday, January 29, 2010 8:29 PM > To: 'Ted Mittelstaedt' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: > CustomerConfidentiality - Time Sensitive > > > >No it does not. Didn't you read your own proposal? It doesn't protect > >hosted and collocated customers AT ALL. It protects the _ISP's_ that > >sell services to those hosted and collocated customers. > > You must be reading something different. My proposal is about obscuring > the > address, phone number and e-mail of a collocated or hosted customer to > prevent poaching by competition. I can use the rational that it > protects > the ISPs customer list and I could also use the "it protects customer > privacy" argument that obviously won 2004-7. > > >Those hosted and collocated customers are businesses that are out there > >paying good money to make themselves known to the world so they can > >sell websites and whatever else they do. Your idea of "protecting" > them > >is to interfere with this process. > > Not all of them. I have a customer, Action Photo. It's a photography > studio run by two people. They colo a server with me and have a /29. I > have > to SWIP their information even though they are the last people that > should > be called if there's an issue and would just end up calling me anyway. > > > >So in other words, your going to slam the previous decision based on > >process and completely ignore the actual discussion itself - and all > you > >have to offer is that ignorant people think it's stupid? > > No. I'm going to change it. There's a process for that and it's the > process I'm going to use. You insinuating that I am somehow trying to > circumvent the system or shove it down people's throat by using my right > to > petition for a draft proposal shows your ignorance of the very system > you > proclaim to be supporting. > > >And your definition of "reasonable" is "agrees with my proposal" > > Are you serious because I'm starting to think you're just messing with > me. > I replied to a post from George Bonser asking how he would change it and > one > from YOU talking about compromise. Make a suggestion. > > Aaron > > > _______________________________________________ > 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. > > > Notice: This e-mail is intended solely for use of the individual or entity > to which it is addressed and may contain information that is proprietary, > privileged, company confidential and/or exempt from disclosure under > applicable law. If the reader is not the intended recipient or agent > responsible for delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If this communication has been > transmitted from a U.S. location it may also contain data subject to the > International Traffic in Arms Regulations or U.S. Export Administration > Regulations and cannot be disseminated, distributed or copied to foreign > nationals, residing in the U.S. or abroad, without the prior approval of the > U.S. Department of State or appropriate export licensing authority. If you > have received this communication in error, please notify the sender by reply > e-mail or collect telephone call and del > ete or destroy all copies of this e-mail message, any physical copies made > of this e-mail message and/or any file attachment(s). > > > > > ------------------------------ > > Message: 3 > Date: Fri, 29 Jan 2010 21:22:20 -0500 > From: Jim McBurnett > To: William Herrin > Cc: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum > Assignment Unit - Correct Title > Message-ID: > > > > Content-Type: text/plain; charset="us-ascii" > > >>That's one reason why letting the ISP decide whether or not to give > >>you a /24 suppresses abuse. > > Bill, > This one item is a perfect example of the sponsorship idea I put at the end > of my last post.. > > Checkbox-- ISP A and ISP B-- Would you assign a /24 to this end user? > Fill in the blank: (why or why not) > > > The ISP's retain the right to have a comment on the assignment.. > Would that calm the concern about abuse? > > > Policy could read: > > Upon submission for an ARIN Assigned PA /24, ARIN will contact both > upstream ISP's via email utilizing the POC for that BGP ASN. > If ISP endorses the request, the request is advanced for further ARIN > consideration. > If ISP does not respond within 5 business days, endorsement is considered > to be implied. > If ISP does not respond favorably, requesting organization is referred to > that ISP and the merits of the > ISP endorsement is considered by ARIN. Where ARIN may or may not advance > the request based on the standing policies at the time. > ISP may rescind or modify their endorsement in a timeline to be published > in the endorsement requesting email from ARIN. > That timeline should not exceed a period of 10 business days. > > > Thoughts? > > Thanks, > Jim > > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 29 Jan 2010 18:51:30 -0800 > From: Ted Mittelstaedt > To: ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: <4B639EB2.1080801 at ipinc.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Leo Bicknell wrote: > > I supported the petition for this proposal. I did that not because > > I think this proposal is perfect, but because I think the issue is > > still important and relevant. Also, as I have already posted, I > > believe there is a new twist on it with respect to IPv6; which may > > not be discussed in this proposal but it can be a vehicle for this > > discussion. > > > > However, this issue is not new. Some of our newer members may not > > understand that. If you were not around for the following discussions, > > you may want to look in the Policy Proposal Archive on ARIN's web > > site, and or reach some back PPML archives.... > > > > 2001-7: Bulk ARIN WHOIS Data > > 2002-4: Bulk Copies of ARIN's WHOIS > > 2002-8: Privatizing POC Information > > 2003-1: Required Performance of Abuse Contact > > 2003-2: Network Abuse > > 2003-5: Distributed Information Server Use Requirements > > 2003-9: WHOIS Acceptable Use Policy (AUP) > > 2003-11: Purpose and scope of WHOIS directory > > 2003-16: POC Verification > > 2004-4: Purpose and scope of ARIN WHOIS directory > > 2004-6: Privacy of Reassignment Information > > 2004-7: Residential Customer Privacy > > 2005-2: Directory Services Overhaul > > 2006-1: Residential Customer Privacy > > 2006-6: Bulk WHOIS agreement expiration clarification > > 2008-1: SWIP support for smaller than /29 assignements > > 2008-7: WHOIS Integrity Policy Proposal > > > > If you want my take on the entire area; the vast majority of folks > > are unhappy with the current state of how SWIP/WHOIS/contact > > information is entered, used and distributed. > > I have to disagree with that. Everyone on this list has not posted > regarding this issue. The people posting are the ones who are > unhappy and the ones (like myself) who think their objections are > unwarranted. But that is not the "majority of folks" It MIGHT be > the "majority of posters" but the posters on both sides are a > minority. > > Also a lot of people are unhappy with how the information is entered > because they don't like the SWIP system and want to replace it with > some webinterface thing, they are not objecting the the actual principle > of making the data available. > > Other RIR's don't seem to have a problem with this data being available > and I frankly think that the reason this topic generates attention > on this list is that because the list is heavy with people from North > America where so much of the Internet connectivity is provided privately > by corporations. > > In the US there is this cultural mythos surrounding the perceived > "business underdog". People root for the small guy against his large > competitors, Microsoft for example was the darling of the hobby market > when it was slugging it out with IBM - then when Microsoft got big > everyone who loved it turned their back on it and now they love Apple, > (and are willing to pay 6 times for a computer for the privilege but > that's a different story). This despite the fact that the little guy > in some cases is providing an inferior product against the big guy. > (ie: the ipod shuffle vs the Sony MP3 walkman) > > The people pushing these "cover your IPs" type proposals like to frame > it as David vs Goliath, due to this mythos, and it always gets good > press, the small struggling ISP being poached by the giant lumbering > ISP who sets their sales dogs to digging into WHOIS. > > The reality is that there isn't significant customer loss from poaching > WHOIS from a business that is doing a good job and keeping it's > customers happy. Speaking from sales experience, trying to poach > customers from a WHOIS list is really, really dumb. A good salesman is > going to define a territory of customers, figure out how to serve > them, then go after them. A territory is commonality between > customers. Some companies use geography as a criteria, some > use type of business. Some use connections and their customer > territory looks senseless from an outside observer until you > find out that all their customers golf at the same course as the > salesman. NO territory I ever heard of a salesman using ever > mapped neatly onto TCP/IP ranges. ISPs do not customarily > group all their medical customers into the same IP range, or > all their construction customers, or all their customers who > run webservers. You could get a better lead > list from pointing a blunderbuss at the phone book and pulling > the trigger and going after anything still readable than by > pulling WHOIS data. At least, with the phone book method, they > would all live in the same area. > > > However, even though > > perhaps 80% of the people are unhappy with the current system, no > > more than 20% of the people can agree on any "solution", and thus > > the status quo always wins. > > > > However I think the sheer number of proposals is proof that the > > status quo is not working for a lot of people. > > > > The sheer number of proposals is frankly because the opponents > of the status quo are arguing on principle, as are the supporters > of the status quo. It is an argument that YOU, Leo, aren't going to > solve, nor am I. It is like the Abortion argument in the US, it's > a fight based on principles on both sides, and it isn't going to > end, ever, no matter what the law is written to say. > > If the status quo was that ARIN covered everything then there > would be just as many proposals to OPEN the database. > > > Sadly though, the discussion has already devolved into useless > > analogies, attacks, lack of understanding, lack of empathy, and > > down right cynicism. Everyone is sure there is some ulterior motive > > involved, to hide a spammer, make money, or game the system. Rather > > than thinking about Joe Average, everyone is talking about the one > > corner case that will always exist, no matter what system we have > > in place. > > > > I am sorry you are so cynical yourself to say that but that > just isn't true. > > As someone else posted this topic is fundamentally an argument > of the Good of the Many outweighing the Good of the Few, or > the One. (for those Trekkies out there) Yes, for some > "corner cases" it might be beneficial to privatize their > SWIPS, if for no other reason than they lack the creativity of > coming up with baloney names for SWIP entries (ie: Universal > Exports, Binford Tools, and the like) But the community would > suffer, as there is currently NO procedure for routine audits > by the RIR of the SWIP data, nor is there ever likely to be, > and almost certainly nobody on this list would be willing to > see their fees increase to pay for one. IPv6 does not change > this because the issue here is reachability of the other guy who > is spamming/attacking/whatever to you vs reachability of the > other guy so you can waste your time trying to poach him. > > History is replete with examples of this kind of argument, over > a great many topics, and there's no shortage of them today. > People get emotional and come up with wild scenarios to prove > their point because this is how these arguments work. And usually > there is not much movement from either side - which is why the > AC tried dropping this proposal in the first place. > > I will close with one last point, and that is the Internet got > to where it is today with the system it has now. That is probably > the most compelling argument that openness in WHOIS was the > right choice in the beginning, as it has WORKED. > > Ted > > > > ------------------------------ > > Message: 5 > Date: Fri, 29 Jan 2010 21:36:23 -0600 > From: Joe Morgan > To: Ted Mittelstaedt > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality > Message-ID: > <38dd4e411001291936i42584c57ne0e1e81088a4e9bd at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Quoting TED > > "I will close with one last point, and that is the Internet got > to where it is today with the system it has now. That is probably > the most compelling argument that openness in WHOIS was the > right choice in the beginning, as it has WORKED." > > I think this just shows how closed minded you are. I have never heard > any intelligent argument that states that just because something > worked it was the best way. I happen to think there is probably always > a better way which is exactly why we have the processes in place that > we do to change things. It is even possible that the internet would be > much better than it is today had some changes been made. Does that > mean I am criticizing the people who worked on it before and the > advances they made? No not at all. I am simply trying to say that just > because it worked and maybe worked in a good way does not mean it was > the best way or that it is the best way for right now. > > On Fri, Jan 29, 2010 at 8:51 PM, Ted Mittelstaedt wrote: > > Leo Bicknell wrote: > >> > >> I supported the petition for this proposal. ?I did that not because > >> I think this proposal is perfect, but because I think the issue is > >> still important and relevant. ?Also, as I have already posted, I > >> believe there is a new twist on it with respect to IPv6; which may > >> not be discussed in this proposal but it can be a vehicle for this > >> discussion. > >> > >> However, this issue is not new. ?Some of our newer members may not > >> understand that. ?If you were not around for the following discussions, > >> you may want to look in the Policy Proposal Archive on ARIN's web > >> site, and or reach some back PPML archives.... > >> > >> 2001-7: Bulk ARIN WHOIS Data > >> 2002-4: Bulk Copies of ARIN's WHOIS > >> 2002-8: Privatizing POC Information > >> 2003-1: Required Performance of Abuse Contact > >> 2003-2: Network Abuse > >> 2003-5: Distributed Information Server Use Requirements > >> 2003-9: WHOIS Acceptable Use Policy (AUP) > >> 2003-11: Purpose and scope of WHOIS directory > >> 2003-16: POC Verification > >> 2004-4: Purpose and scope of ARIN WHOIS directory > >> 2004-6: Privacy of Reassignment Information > >> 2004-7: Residential Customer Privacy > >> 2005-2: Directory Services Overhaul > >> 2006-1: Residential Customer Privacy > >> 2006-6: Bulk WHOIS agreement expiration clarification > >> 2008-1: SWIP support for smaller than /29 assignements > >> 2008-7: WHOIS Integrity Policy Proposal > >> > >> If you want my take on the entire area; the vast majority of folks > >> are unhappy with the current state of how SWIP/WHOIS/contact > >> information is entered, used and distributed. > > > > I have to disagree with that. ?Everyone on this list has not posted > > regarding this issue. ?The people posting are the ones who are > > unhappy and the ones (like myself) who think their objections are > > unwarranted. ?But that is not the "majority of folks" ?It MIGHT be > > the "majority of posters" but the posters on both sides are a > > minority. > > > > Also a lot of people are unhappy with how the information is entered > > because they don't like the SWIP system and want to replace it with > > some webinterface thing, they are not objecting the the actual principle > > of making the data available. > > > > Other RIR's don't seem to have a problem with this data being available > > and I frankly think that the reason this topic generates attention > > on this list is that because the list is heavy with people from North > > America where so much of the Internet connectivity is provided privately > by > > corporations. > > > > In the US there is this cultural mythos surrounding the perceived > > "business underdog". ?People root for the small guy against his large > > competitors, Microsoft for example was the darling of the hobby market > > when it was slugging it out with IBM - then when Microsoft got big > > everyone who loved it turned their back on it and now they love Apple, > > (and are willing to pay 6 times for a computer for the privilege but > > that's a different story). ?This despite the fact that the little guy > > in some cases is providing an inferior product against the big guy. > > (ie: the ipod shuffle vs the Sony MP3 walkman) > > > > The people pushing these "cover your IPs" type proposals like to frame > > it as David vs Goliath, due to this mythos, and it always gets good > > press, the small struggling ISP being poached by the giant lumbering > > ISP who sets their sales dogs to digging into WHOIS. > > > > The reality is that there isn't significant customer loss from poaching > > WHOIS from a business that is doing a good job and keeping it's customers > > happy. ?Speaking from sales experience, trying to poach customers from a > > WHOIS list is really, really dumb. ?A good salesman is > > going to define a territory of customers, figure out how to serve > > them, then go after them. ?A territory is commonality between > > customers. ?Some companies use geography as a criteria, some > > use type of business. Some use connections and their customer > > territory looks senseless from an outside observer until you > > find out that all their customers golf at the same course as the > > salesman. ?NO territory I ever heard of a salesman using ever > > mapped neatly onto TCP/IP ranges. ?ISPs do not customarily > > group all their medical customers into the same IP range, or > > all their construction customers, or all their customers who > > run webservers. ?You could get a better lead > > list from pointing a blunderbuss at the phone book and pulling > > the trigger and going after anything still readable than by > > pulling WHOIS data. ?At least, with the phone book method, they > > would all live in the same area. > > > >> ?However, even though > >> > >> perhaps 80% of the people are unhappy with the current system, no > >> more than 20% of the people can agree on any "solution", and thus > >> the status quo always wins. > >> > >> However I think the sheer number of proposals is proof that the > >> status quo is not working for a lot of people. > >> > > > > The sheer number of proposals is frankly because the opponents > > of the status quo are arguing on principle, as are the supporters > > of the status quo. ?It is an argument that YOU, Leo, aren't going to > > solve, nor am I. ?It is like the Abortion argument in the US, it's > > a fight based on principles on both sides, and it isn't going to > > end, ever, no matter what the law is written to say. > > > > If the status quo was that ARIN covered everything then there > > would be just as many proposals to OPEN the database. > > > >> Sadly though, the discussion has already devolved into useless > >> analogies, attacks, lack of understanding, lack of empathy, and > >> down right cynicism. ?Everyone is sure there is some ulterior motive > >> involved, to hide a spammer, make money, or game the system. ?Rather > >> than thinking about Joe Average, everyone is talking about the one > >> corner case that will always exist, no matter what system we have > >> in place. > >> > > > > I am sorry you are so cynical yourself to say that but that > > just isn't true. > > > > As someone else posted this topic is fundamentally an argument > > of the Good of the Many outweighing the Good of the Few, or > > the One. ?(for those Trekkies out there) ?Yes, for some > > "corner cases" it might be beneficial to privatize their > > SWIPS, if for no other reason than they lack the creativity of > > coming up with baloney names for SWIP entries (ie: Universal > > Exports, Binford Tools, and the like) ?But the community would > > suffer, as there is currently NO procedure for routine audits > > by the RIR of the SWIP data, nor is there ever likely to be, > > and almost certainly nobody on this list would be willing to > > see their fees increase to pay for one. ?IPv6 does not change > > this because the issue here is reachability of the other guy who > > is spamming/attacking/whatever to you vs reachability of the > > other guy so you can waste your time trying to poach him. > > > > History is replete with examples of this kind of argument, over > > a great many topics, and there's no shortage of them today. > > People get emotional and come up with wild scenarios to prove > > their point because this is how these arguments work. ?And usually > > there is not much movement from either side - which is why the > > AC tried dropping this proposal in the first place. > > > > I will close with one last point, and that is the Internet got > > to where it is today with the system it has now. ?That is probably > > the most compelling argument that openness in WHOIS was the > > right choice in the beginning, as it has WORKED. > > > > Ted > > > > _______________________________________________ > > 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. > > > > > > -- > Thank You, > Joe Morgan > Joe's Datacenter, LLC > http://joesdatacenter.com > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 55, Issue 73 > ***************************************** > -- Rudi Daniel e Business Consultant http://www.svgpso.org http://oecstimes.wordpress.com ?The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.? - Bertrand Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Sat Jan 30 15:57:47 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 30 Jan 2010 12:57:47 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <8aeeaff61001291230m6ef7a12fy7d33d53d4873c68@mail.gmail.com> References: <8aeeaff61001291230m6ef7a12fy7d33d53d4873c68@mail.gmail.com> Message-ID: <4B649D4B.3080707@rollernet.us> On 1/29/2010 12:30, Rudolph Daniel wrote: > What I think is at the center of the debate here is : How much > information and what kind of information is to be in the public view. It > is not about whether the information exists. ARIN has the information > and a provider has collected the information and passed it to ARIN. > > Now, under what rules and circumstances can/should that information be > accessed and by whom and for what purpose. Disclosure on a need to know > basis is also something I am not not 100% clear on. > If I see an unusual ip on my server, under what circumstances do I need > detailed information on who it is allocated to? And how do I efficiently > access that information if it is not an open public record. If it were > on public record, what level of certainty do I have that the information > is accurate? > If it is not on public record and I give good reason to access it, then > the entity allocated that record has a right to know / have recorded... > who accessed the information and when. Where the information is simply > public view, there is more room for abuse of that information simply > because there are "fewer" controls on what is published. > My general feeling is that if I see a misbehaving bunch of IP addresses and I need to nuke it, I'll follow whatever the owner feels like showing in whois. If the most detail I get is a /19 because the details are super secret, then /19 is what I'll block. ~Seth From owen at delong.com Sat Jan 30 20:53:33 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 30 Jan 2010 17:53:33 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <05da01caa140$e111f5f0$a335e1d0$@net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net> <4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net> Message-ID: <6F8A7E70-D8D5-4B5A-9BD4-D4412455E27E@delong.com> On Jan 29, 2010, at 4:12 PM, Aaron Wendel wrote: > >> You can support the idea but not the proposal. I definitely don't >> support the proposal. I am willing to look at the idea, however. If >> you can make a logical argument that the current policy as written >> makes it impossible for ISP's to exclude private individuals or >> residences in certain circumstances, I'd support a modification to >> current policy. > > I'm not sure I understand what you mean. Residential customers are already > covered under a separate policy allowing them to be deemed "private". My > proposal provides equal protection for hosted and collocated customers. > Except that it does not. It provides somewhat similar protection (if you could call it that), but, on very different terms. The proposal as written allows an ISP to exclude the contact data for their customers solely at the ISP's discretion and allows the ISP to obfuscate ALL contact data, not merely the name and street address. The proposal makes this ability to obfuscate the data from public view solely at the discretion of the ISP and not their customer. Claiming that it extends the same protections as the residential customer privacy is disingenuous at best, and, potentially very misleading to those less familiar with the terms of the two policies. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Jan 31 02:15:04 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 30 Jan 2010 23:15:04 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B63865F.7070608@ipinc.net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net> Message-ID: On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote: > David Farmer wrote: >> Thanks, Ted that was a good summary. >> Ted Mittelstaedt wrote: >>> Naturally the AC will need to make the "official" determination >>> but it looks like we will be discussing this. >> Actually that is Staff's job, if the AC did that, it would be the fox guarding the chicken coop. The the Staff is much better at counting then us on the AC anyway, you know they have to count out each IP address right, just like a teller does at the bank. :) Talk about a barrier to IPv6 adoption. :) (only kidding) ARIN Staff is great!!! >> But, I believe most of the AC was watching, I know I was. >>> Marshall your arguments! :-) >> And yes you should do that, may I suggest everyone take a step back and take a breath first. >> So, a little more serious now; >> I would like to ask the community to think about how we all want this to work. Personally, I've been waiting for the petition process to kick in. I actually think it is a healthy thing and shows the process is working. But, we are setting precedent, this is the first petition for the new PDP, so lets try to make it good precedent and all do our part to make the system work. The first use of the Emergency PDP last year, wasn't the greatest experience for our community. I would hope we can make this first a much better experience for us all. >> And we all will play a part in making it a good experience. >> This got people charged up, > > Of course it did. The success of the petition means one thing - that > the AC made a bad decision. > I disagree. I think the AC made the absolutely correct decision and that the petition means that 10 or more members of the community disagree with the AC's decision sufficiently strongly that they successfully petitioned it. That's how the process is supposed to work. There's nothing wrong with it. I think in the end, it is likely that the community as a whole will uphold the AC's decision, but, in this case, there's enough dissent that it merits consideration of the full community and that's what is happening. > > My only observation on this is that I think if the AC had been > more specific (and long) on the explanation of why it was dropped > that people might not have supported the petition. > Perhaps. I guess there's a question of resource allocation there in terms of how much AC time should be spent justifying a decision to abandon vs. focusing on things still on the docket. I'm not saying we did the absolutely correct thing in this case, merely that there is a tradeoff to be considered that isn't part of your previous paragraph. Owen > They are not writing a UNIX man page, after all. > Yeah, but, we don't have time to write War and Peace, either. Unlike the supreme court, we aren't flooded with volunteer students seeking to put Law Clerk in the Supreme Court on their resume. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Jan 31 02:32:06 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 30 Jan 2010 23:32:06 -0800 Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality In-Reply-To: <064a01caa14a$9a8f12c0$cfad3840$@net> References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com> <6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com> <5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com> <060b01caa144$66614820$3323d860$@net> <5A6D953473350C4B9995546AFE9939EE081F74E2@RWC-EX1.corp.seven.com> <064a01caa14a$9a8f12c0$cfad3840$@net> Message-ID: Um, in such a case, wouldn't it be appropriate for that to be an end-user assignment and no SWIP is required because the network is under the control of the end-user organization? Current policy seems to cover that case. Owen On Jan 29, 2010, at 5:21 PM, Aaron Wendel wrote: > Ok. How would you change the wording to reflect that? > > Aaron > > > -----Original Message----- > From: George Bonser [mailto:gbonser at seven.com] > Sent: Friday, January 29, 2010 7:16 PM > To: Aaron Wendel > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal 95: Customer Confidentiality > > > >> -----Original Message----- >> From: Aaron Wendel [mailto:aaron at wholesaleinternet.net] >> Sent: Friday, January 29, 2010 4:37 PM >> To: George Bonser >> Cc: arin-ppml at arin.net >> Subject: RE: [arin-ppml] Policy Proposal 95: Customer Confidentiality >> >> What is the proposal distinguished between "Hosted" customers and >> "Downstream" customers? Meaning that if they have infrastructure in a >> datacenter you control verses receive transit service from you in > their >> own >> facility. What would you think of that? >> >> Aaron > > The only way such a proposal to have only the provider's contact info > makes any sense is if the provider is basically the "operator" of the > network and there is no other path to the internet except through that > provider. Once there are multiple ways out and/or the customer manages > the network themselves, they need to be listed. > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release Date: 01/29/10 > 13:35:00 > > _______________________________________________ > 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 Sun Jan 31 04:14:17 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 31 Jan 2010 01:14:17 -0800 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <065001caa14b$9a626800$cf273800$@net> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <05a901caa13b$4cd154d0$e673fe70$@net> <4B637523.1070708@ipinc.net> <05da01caa140$e111f5f0$a335e1d0$@net> <4B6384A4.4040304@ipinc.net> <065001caa14b$9a626800$cf273800$@net> Message-ID: <66FAFE30-CC74-48CC-A4F2-4B62CD57B65C@delong.com> On Jan 29, 2010, at 5:28 PM, Aaron Wendel wrote: > >> No it does not. Didn't you read your own proposal? It doesn't protect >> hosted and collocated customers AT ALL. It protects the _ISP's_ that >> sell services to those hosted and collocated customers. > > You must be reading something different. My proposal is about obscuring the > address, phone number and e-mail of a collocated or hosted customer to > prevent poaching by competition. I can use the rational that it protects > the ISPs customer list and I could also use the "it protects customer > privacy" argument that obviously won 2004-7. > Except that businesses don't have such a right to privacy as residential customers may. Generally, legitimate businesses do not intend to be anonymous (ServerVault's special class(es) of arguably nefarious customers aside, which aren't exactly businesses in most cases, either). If it were intended to protect customer privacy, then, at best it should mention that the choice is entirely up to the customer, and, in the case of non-residential services I would argue that the default should clearly be in favor of publication absent a specific customer request. The ISP should be required to produce documentation of the customer request for ARIN on request. >> Those hosted and collocated customers are businesses that are out there >> paying good money to make themselves known to the world so they can >> sell websites and whatever else they do. Your idea of "protecting" them >> is to interfere with this process. > > Not all of them. I have a customer, Action Photo. It's a photography > studio run by two people. They colo a server with me and have a /29. I have > to SWIP their information even though they are the last people that should > be called if there's an issue and would just end up calling me anyway. > So you run their antivirus software and clean their machines if they get infected? If it's that level of managed service, then, arguably their machines are part of your infrastructure from an administrative perspective. If you are the end-user, you don't need to swip the space as a customer assignment. If someone else administers the machines, then, that someone else should be on the SWIP. > Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Jan 31 11:35:47 2010 From: bill at herrin.us (William Herrin) Date: Sun, 31 Jan 2010 11:35:47 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net> Message-ID: <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> On Sun, Jan 31, 2010 at 2:15 AM, Owen DeLong wrote: > On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote: >> Of course it did. ?The success of the petition means one thing - that >> the AC made a bad decision. > > I disagree. ?I think the AC made the absolutely correct decision and that > the petition means that 10 or more members of the community disagree > with the AC's decision sufficiently strongly that they successfully > petitioned it. That's how the process is supposed to work. ?There's > nothing wrong with it. Hi Owen, That depends whether this one incident becomes a pattern. One incident standing alone means the process is working as intended. A pattern of incidents, should one develop, would mean that the AC is suppressing public participation. Something to consider the next time you vote to abandon a policy simply because you think it's "bad." That isn't what you were elected to do. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Sun Jan 31 13:56:36 2010 From: farmer at umn.edu (David Farmer) Date: Sun, 31 Jan 2010 12:56:36 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4731325D-AEE3-4521-AA9C-12FD9907924F@delong.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4731325D-AEE3-4521-AA9C-12FD9907924F@delong.com> Message-ID: <4B65D264.6070003@umn.edu> Thanks for the correction Owen. What I meant to say was, this is the first successful petition. That is assuming ARIN Staff certifies it as a successful petition, which I expect they will. Owen DeLong wrote: > This isn't the first petition under the new PDP... It's the first one to gain enough signatures. > > Owen > > On Jan 29, 2010, at 4:42 PM, David Farmer wrote: > >> Thanks, Ted that was a good summary. >> >> Ted Mittelstaedt wrote: >>> Naturally the AC will need to make the "official" determination >>> but it looks like we will be discussing this. >> Actually that is Staff's job, if the AC did that, it would be the fox guarding the chicken coop. The the Staff is much better at counting then us on the AC anyway, you know they have to count out each IP address right, just like a teller does at the bank. :) Talk about a barrier to IPv6 adoption. :) (only kidding) ARIN Staff is great!!! >> >> But, I believe most of the AC was watching, I know I was. >>> Marshall your arguments! :-) >> And yes you should do that, may I suggest everyone take a step back and take a breath first. >> >> So, a little more serious now; >> >> I would like to ask the community to think about how we all want this to work. Personally, I've been waiting for the petition process to kick in. I actually think it is a healthy thing and shows the process is working. But, we are setting precedent, this is the first petition for the new PDP, so lets try to make it good precedent and all do our part to make the system work. The first use of the Emergency PDP last year, wasn't the greatest experience for our community. I would hope we can make this first a much better experience for us all. >> >> And we all will play a part in making it a good experience. >> >> This got people charged up, but could you use a little of that energy and look that the other proposals, 101, 106, and 107. The AC need to finish up the text for these to go to staff and legal review, by EOB Monday. PP#101 has new language I sent out a couple days ago. >> >> PP#106 Scot and I are working on, and would hope we get some new text out. >> >> PP#107 I will be sending some more changes shortly based on feed back from the staff clarity review. >> >> Thanks and I hope to see many of you in Toronto. >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Sun Jan 31 14:34:08 2010 From: farmer at umn.edu (David Farmer) Date: Sun, 31 Jan 2010 13:34:08 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net> <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> Message-ID: <4B65DB30.6080200@umn.edu> William Herrin wrote: > On Sun, Jan 31, 2010 at 2:15 AM, Owen DeLong wrote: >> On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote: >>> Of course it did. The success of the petition means one thing - that >>> the AC made a bad decision. >> I disagree. I think the AC made the absolutely correct decision and that >> the petition means that 10 or more members of the community disagree >> with the AC's decision sufficiently strongly that they successfully >> petitioned it. That's how the process is supposed to work. There's >> nothing wrong with it. > > Hi Owen, > > That depends whether this one incident becomes a pattern. One incident > standing alone means the process is working as intended. A pattern of > incidents, should one develop, would mean that the AC is suppressing > public participation. I would like to point out that PP#95 was originally put forward in June 2009, the AC decided it wouldn't be part of the Dearborn PPM, I supported this as I thought we had more important thins to work on. It became clear that we the AC wasn't not going to have something ready for the Toronto PPM. I therefore supported abandoning the proposal, at this time because it didn't make sense to me for us to keep it on our docket and not actually make any progress on it. Please remember the members of the AC are volunteers, we all have day jobs too, so there is a limit to how much we can accomplish. Please don't think I'm saying this this issue is not important, I just believe we have had issue that were more important and we have been working on those. I think we had every intention to work on PP#95, but events proceeded differently that we intended. Personally, I tend to agree with Leo that if we take this on it should focus on IPv6 and how we want this to work in IPv6, then look at if that maps back into any changes for IPv4. While I did not and do not support the petition, I do think there are more important things for the community to be working on. I do support the petition process and believe it is a healthy thing for our community. Think of it this way, the AC pushed this one back for the community to decide, rather than holding this proposal hostage on our docket. > Something to consider the next time you vote to abandon a policy > simply because you think it's "bad." That isn't what you were elected > to do. Something for you to think about is that when the AC abandons a proposal it doesn't necessarily mean we think it is a bad idea. It might mean that we don't have time for it now, that we want the community to decide if it should go forward, or that we honestly just don't know what to do with it, these are perfectly valid reasons to abandon a proposal too. > Regards, > Bill Herrin -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Sun Jan 31 16:27:01 2010 From: bill at herrin.us (William Herrin) Date: Sun, 31 Jan 2010 16:27:01 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B65DB30.6080200@umn.edu> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net> <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> <4B65DB30.6080200@umn.edu> Message-ID: <3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> On Sun, Jan 31, 2010 at 2:34 PM, David Farmer wrote: > I would like to point out that PP#95 was originally put forward in June > 2009, the AC decided it wouldn't be part of the Dearborn PPM, I supported > this as I thought we had more important thins to work on. ?It became clear > that we the AC wasn't not going to have something ready for the Toronto PPM. > ?I therefore supported abandoning the proposal, at this time because it > didn't make sense to me for us to keep it on our docket and not actually > make any progress on it. How is that delay possible anyway? Section 2.2 in the PDP reads in part: "Council must make a decision regarding any policy proposal at their next regularly scheduled meeting that occurs after the Advisory Council receives the Clarity and Understanding Report from staff. If the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting, but the period shall not be extended beyond 45 days." I haven't examined the schedule in detail but it seems to me that more time than that has elapsed since June 2009. > Something for you to think about is that when the AC abandons a proposal it > doesn't necessarily mean we think it is a bad idea. It might mean that we > don't have time for it now, that we want the community to decide if it > should go forward, or that we honestly just don't know what to do with it, > these are perfectly valid reasons to abandon a proposal too. If its an actionable proposal but you "don't know what to do with it" it seems bloody obvious to me that you should advance the proposal and let the community determine what to do with it. Sitting in judgment is the board's job. Yours is advising: first the proposal authors, second the community at large and only as a distant third advising the board. In proposal 95 as well as other recent proposals, it seems to me you guys have skipped the "advising" part and move straight to judgment. > Please remember the members of the AC are volunteers, we all have day jobs > too, so there is a limit to how much we can accomplish. I have a day job too, yet I've found the time to write thorough and well supported proposals only to have the AC "fail to find the time" for them. I'm not so concerned about you but what about the the half of the AC who can't even find time to participate on PPML? Marla Azinger. Last PPML post September 2009 Stacy Hughes. Last PPML post September 2009 Heather Schiller. Last PPML post: July 2009 Dan Alexander. Last PPML post: June 2009 Bill Sandiford. Posted a message on the PPML exactly once. Marc Crandall. Has he *ever* participated on the PPML? Tom Zeller. No participation identified in the last decade of PPML archives. Do you realize that only five of the fifteen of you have participated in the PUBLIC policy mailing list this month? I'm calling a Whisky Tango Foxtrot here. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rudi.daniel at gmail.com Sun Jan 31 18:53:22 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 31 Jan 2010 19:53:22 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 55, Issue 75 In-Reply-To: References: Message-ID: <8aeeaff61001311553m7d27f522q6d51db5d09cabc4c@mail.gmail.com> > > On 1/29/2010 12:30, Rudolph Daniel wrote: > > What I think is at the center of the debate here is : How much > > information and what kind of information is to be in the public view. It > > is not about whether the information exists. ARIN has the information > > and a provider has collected the information and passed it to ARIN. > > > > Now, under what rules and circumstances can/should that information be > > accessed and by whom and for what purpose. Disclosure on a need to know > > basis is also something I am not not 100% clear on. > > If I see an unusual ip on my server, under what circumstances do I need > > detailed information on who it is allocated to? And how do I efficiently > > access that information if it is not an open public record. If it were > > on public record, what level of certainty do I have that the information > > is accurate? > > If it is not on public record and I give good reason to access it, then > > the entity allocated that record has a right to know / have recorded... > > who accessed the information and when. Where the information is simply > > public view, there is more room for abuse of that information simply > > because there are "fewer" controls on what is published. > > > > My general feeling is that if I see a misbehaving bunch of IP addresses > and I need to nuke it, I'll follow whatever the owner feels like showing > in whois. If the most detail I get is a /19 because the details are > super secret, then /19 is what I'll block. > > ~Seth > You would be demanding instant attention in that case. And if all u get is /19, with no other indication at all, then yes I guess its one of your options. RD -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Sun Jan 31 19:20:23 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 31 Jan 2010 20:20:23 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 55, Issue 76 In-Reply-To: References: Message-ID: <8aeeaff61001311620ufd7f149na4f8a5b9fd79ea33@mail.gmail.com> I really cannot see any conceivable value in the argument that the AC can make a bad decision. Decision yes but never a bad decision. The processes surely, allows the community to reflect on decisions made by the AC through the petition process. And are 10 or more members of the community going to challenge an AC decision just for the hell of it? I think not. RD On Sun, Jan 31, 2010 at 2:15 AM, Owen DeLong wrote: > > On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote: > >> Of course it did. ?The success of the petition means one thing - that > >> the AC made a bad decision. > > > > I disagree. ?I think the AC made the absolutely correct decision and that > > the petition means that 10 or more members of the community disagree > > with the AC's decision sufficiently strongly that they successfully > > petitioned it. That's how the process is supposed to work. ?There's > > nothing wrong with it. > > Hi Owen, > > That depends whether this one incident becomes a pattern. One incident > standing alone means the process is working as intended. A pattern of > incidents, should one develop, would mean that the AC is suppressing > public participation. > > Something to consider the next time you vote to abandon a policy > simply because you think it's "bad." That isn't what you were elected > to do. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 55, Issue 76 > ***************************************** > -- Rudi Daniel e Business Consultant http://www.svgpso.org http://oecstimes.wordpress.com ?The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.? - Bertrand Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Sun Jan 31 19:25:40 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sun, 31 Jan 2010 16:25:40 -0800 Subject: [arin-ppml] ARIN-PPML Digest, Vol 55, Issue 76 In-Reply-To: <8aeeaff61001311620ufd7f149na4f8a5b9fd79ea33@mail.gmail.com> References: <8aeeaff61001311620ufd7f149na4f8a5b9fd79ea33@mail.gmail.com> Message-ID: On Jan 31, 2010, at 4:20 PM, Rudolph Daniel wrote: > > I really cannot see any conceivable value in the argument that the > AC can make a bad decision. Decision yes but never a bad decision. I disagree. We all can and do make bad decisions. > The processes surely, allows the community to reflect on decisions > made by the AC through the petition process. Exactly. We must remain answerable to the entire community, and the petition process is one way to make sure that happens. -Scott > > > > > On Sun, Jan 31, 2010 at 2:15 AM, Owen DeLong wrote: > > On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote: > >> Of course it did. ?The success of the petition means one thing - > that > >> the AC made a bad decision. > > > > I disagree. ?I think the AC made the absolutely correct decision > and that > > the petition means that 10 or more members of the community disagree > > with the AC's decision sufficiently strongly that they successfully > > petitioned it. That's how the process is supposed to work. ?There's > > nothing wrong with it. > > Hi Owen, > > That depends whether this one incident becomes a pattern. One incident > standing alone means the process is working as intended. A pattern of > incidents, should one develop, would mean that the AC is suppressing > public participation. > > Something to consider the next time you vote to abandon a policy > simply because you think it's "bad." That isn't what you were elected > to do. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 55, Issue 76 > ***************************************** > > > > -- > Rudi Daniel > e Business Consultant > http://www.svgpso.org > http://oecstimes.wordpress.com > ?The whole problem with the world is that fools and fanatics are alw > ays so certain of themselves, but wiser people so full of doubts.? - > Bertrand Russell > _______________________________________________ > 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 farmer at umn.edu Sun Jan 31 19:50:31 2010 From: farmer at umn.edu (David Farmer) Date: Sun, 31 Jan 2010 18:50:31 -0600 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net> <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> <4B65DB30.6080200@umn.edu> <3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> Message-ID: <4B662557.5000202@umn.edu> William Herrin wrote: > On Sun, Jan 31, 2010 at 2:34 PM, David Farmer wrote: >> I would like to point out that PP#95 was originally put forward in June >> 2009, the AC decided it wouldn't be part of the Dearborn PPM, I supported >> this as I thought we had more important thins to work on. It became clear >> that we the AC wasn't not going to have something ready for the Toronto PPM. >> I therefore supported abandoning the proposal, at this time because it >> didn't make sense to me for us to keep it on our docket and not actually >> make any progress on it. > > How is that delay possible anyway? Section 2.2 in the PDP reads in part: > > "Council must make a decision regarding any policy proposal at their > next regularly scheduled meeting that occurs after the Advisory > Council receives the Clarity and Understanding Report from staff. If > the period before the next regularly scheduled meeting is less than 10 > days, then the period may be extended to the subsequent regularly > scheduled meeting, but the period shall not be extended beyond 45 > days." > > I haven't examined the schedule in detail but it seems to me that more > time than that has elapsed since June 2009. It was publicly announced, see: http://lists.arin.net/pipermail/arin-ppml/2009-June/014661.html I thought it was announced at some point that this was petitionable, but I can't seem to find it. If it wasn't that was probably a mistake on our part, but I don't believe there was any intent to deceive anyone. The PDP is just a year old and we haven't figured it all out yet. >> Something for you to think about is that when the AC abandons a proposal it >> doesn't necessarily mean we think it is a bad idea. It might mean that we >> don't have time for it now, that we want the community to decide if it >> should go forward, or that we honestly just don't know what to do with it, >> these are perfectly valid reasons to abandon a proposal too. > > If its an actionable proposal but you "don't know what to do with it" > it seems bloody obvious to me that you should advance the proposal and > let the community determine what to do with it. Sitting in judgment is > the board's job. Yours is advising: first the proposal authors, second > the community at large and only as a distant third advising the board. > > In proposal 95 as well as other recent proposals, it seems to me you > guys have skipped the "advising" part and move straight to judgment. > > >> Please remember the members of the AC are volunteers, we all have day jobs >> too, so there is a limit to how much we can accomplish. > > I have a day job too, yet I've found the time to write thorough and > well supported proposals only to have the AC "fail to find the time" > for them. > > I'm not so concerned about you but what about the the half of the AC > who can't even find time to participate on PPML? > > Marla Azinger. Last PPML post September 2009 > Stacy Hughes. Last PPML post September 2009 > Heather Schiller. Last PPML post: July 2009 > Dan Alexander. Last PPML post: June 2009 > Bill Sandiford. Posted a message on the PPML exactly once. > Marc Crandall. Has he *ever* participated on the PPML? > Tom Zeller. No participation identified in the last decade of PPML archives. > > Do you realize that only five of the fifteen of you have participated > in the PUBLIC policy mailing list this month? I'll just point out not everyone participates in the same way, and this is a good thing, there are other roles to play than opinionated guy who shoots his mouth off a lot, that I some time play. We do need quite contemplative thinkers too. I believe the AC is a well rounded group and there are many different roles to be played on the AC. I don't think it would serve the community well if we all thought and acted the same. I can tell you that all of the people on your list above have contributed in their own ways, even if it wasn't to post to PPML. > I'm calling a Whisky Tango Foxtrot here. That is your right and if you think it is necessary you should. > Regards, > Bill Herrin > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at telnetcommunications.com Sun Jan 31 20:40:27 2010 From: bill at telnetcommunications.com (Bill Sandiford) Date: Sun, 31 Jan 2010 20:40:27 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net> <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> <4B65DB30.6080200@umn.edu> <3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> Message-ID: William Herrin wrote: > > > Marla Azinger. Last PPML post September 2009 > Stacy Hughes. Last PPML post September 2009 > Heather Schiller. Last PPML post: July 2009 > Dan Alexander. Last PPML post: June 2009 > Bill Sandiford. Posted a message on the PPML exactly once. > Marc Crandall. Has he *ever* participated on the PPML? > Tom Zeller. No participation identified in the last decade of PPML > archives. > Hi Bill: I can't speak for any of the others, but I have only sat on the AC for a grand total of 31 days now. After being elected, I decided that I was going observe for a little while before getting vocal. I felt it was prudent to do so. I also found that while observing, Scott, Owen, and David usually ask a lot of the questions that I would ask anyways. I'm not about to repeat those questions ad nauseum just to increase my "post count". The fact that I have not been *posting* does not mean that I (or the others for that matter) haven't spent a considerable amount of time *reading* the emails of others that are sent to PPML. By my count there have been ~350 emails since January 31st alone, the reading of which takes a considerable amount of time. I also appreciate that there are people like yourself that have spent the same amount of time reading and participating as well. To summarize, just because I'm not posting, does not mean I'm not doing my job as an AC member. I'm reading, gauging community opinion/consensus, and taking that feedback into consideration when the AC meets in order to create/advance good policy. I look forward to meeting you and others of the community at the upcoming PPM in Toronto (my home town). Regards, Bill Sandiford From bill at herrin.us Sun Jan 31 23:32:10 2010 From: bill at herrin.us (William Herrin) Date: Sun, 31 Jan 2010 23:32:10 -0500 Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive In-Reply-To: <4B662557.5000202@umn.edu> References: <02c701caa054$b71df010$2559d030$@net> <4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net> <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> <4B65DB30.6080200@umn.edu> <3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> <4B662557.5000202@umn.edu> Message-ID: <3c3e3fca1001312032raec9c5ek7478e2444c584c25@mail.gmail.com> On Sun, Jan 31, 2010 at 7:50 PM, David Farmer wrote: > William Herrin wrote: >> Do you realize that only five of the fifteen of you have participated >> in the PUBLIC policy mailing list this month? > > I'll just point out not everyone participates in the same way, and this is a > good thing, there are other roles to play than opinionated guy who shoots > his mouth off a lot, that I some time play. ?We do need quite contemplative > thinkers too. ?I believe the AC is a well rounded group and there are many > different roles to be played on the AC. ?I don't think it would serve the > community well if we all thought and acted the same. ?I can tell you that > all of the people on your list above have contributed in their own ways, > even if it wasn't to post to PPML. David, I'm not trying to single out anyone, but frankly I'm frustrated by the AC's collective behavior this past year and I doubt I'm the only one. I'd be far more sympathetic if all the quiet work outside the public eye resulted more and better advice for proposal authors from among the general public, and less suppression of proposals not written by members of the AC itself. Take an instructive look at the proposals abandoned prior to formal discussion over the past 18 months: First, the ones authored by the members of the AC: 96. Abandoned because it was process rather than policy. Referred to the ARIN President for further action. 91. Abandoned without comment, presumably because it was principally a challenge to a Board of Trustees action. I note that it was abandoned despite significant support for the proposal among the community. 87. Abandoned after ARIN staff procedures were altered to accomplish the same result. 85: Abandoned in favor of proposal 91 by the same AC member. Now look at the difference with the ones authored by the general public: 104, 103: Abandoned because "the AC could not support this proposal in its current form" 100: Abandoned without comment as the AC advanced a similar proposal written by one of its members. 98: Abandoned because "the proposal is overly complicated." 95: Abandoned because it resembles a proposal defeated half a decade ago. 92: Abandoned because "The AC [...] does not believe that the problem addressed is immediate nor of sufficient scope" 88: Abandoned without comment. 86: Abandoned on the grounds that modifications to the policy development process can not be made through the policy development process. 83: Abandoned "seeing little support and a large amount of opposition on PPML." Have I painted a clear enough picture or do I need to spell it out? The insiders' right to advance a proposal is almost undisputed while the evaluation of bottom-up policy has progressed from "seeing little [public] support" to "the AC could not support." The BoT has thrown you a nasty conflict of interest by having you sit in judgment on your own proposals as well as those from the general public . Quite frankly you are, as a group, handling it poorly. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Sun Jan 31 23:59:53 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 31 Jan 2010 20:59:53 -0800 Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title In-Reply-To: <3c3e3fca1001291721j637e073bwb7c0865aad9282c9@mail.gmail.com> References: <4B58C4A5.2000406@arin.net> <4B58D31E.1090602@ipinc.net> <9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> <3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> <62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com> <3c3e3fca1001291157s1c4b9c68rf4f78578ac0aa4d1@mail.gmail.com> <3c3e3fca1001291721j637e073bwb7c0865aad9282c9@mail.gmail.com> Message-ID: On Jan 29, 2010, at 5:21 PM, William Herrin wrote: > On Fri, Jan 29, 2010 at 7:46 PM, Jim McBurnett wrote: >> 1. If an end user gets a /24 IP address space from an ISP via the /24 MH rule-- >> Why such a big difference in PA from ARIN? >> BUT does the ISP check usage? > > Hi Jim, > > As a thought experiment: if you buy a $20 Verizon residential DSL > account, and ask Verizon to give you a /24 because you also have a Cox > cable modem, what sort of response do you expect? Bear in mind that a > /24 for multihoming means they have to reprogram their border routers > not to reject packets originating from that /24. > > If you ask ARIN for a /24 justified because you have Internet > contracts with Verizon and Cox Business Services, what sort of > response do you expect? > > That's one reason why letting the ISP decide whether or not to give > you a /24 suppresses abuse. > I suppose that depends on how you define abuse. If you ask the ISP and they refuse, but, you have a legitimate reason for wanting to multihome, isn't that another form of abuse? Owen