From andrew.dul at quark.net Thu May 1 12:30:03 2008 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 01 May 2008 08:30:03 -0800 Subject: [arin-ppml] 134.17.0.0/16 Message-ID: <20080501163003.2883.qmail@hoster908.com> http://blog.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html From jlewis at lewis.org Thu May 1 12:51:26 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 1 May 2008 12:51:26 -0400 (EDT) Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: <20080501163003.2883.qmail@hoster908.com> References: <20080501163003.2883.qmail@hoster908.com> Message-ID: On Thu, 1 May 2008, Andrew Dul wrote: > http://blog.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html This is kind of old news, but it'll be very interesting to see how ARIN handles it, and if it ends up in court, how it's decided. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dylan.ebner at crlmed.com Thu May 1 13:11:10 2008 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Thu, 1 May 2008 11:11:10 -0600 Subject: [arin-ppml] 134.17.0.0/16 References: <20080501163003.2883.qmail@hoster908.com> Message-ID: Does ARIN have any kind of policy for recommendations to be made to it's members for dealing with this kind of accused abuse? Does ARIN recommend that other organizations block incomming traffic from these "hijacked" IP blocks? I am curious to what people's opinion is on this matter. Should the ARIN community try to block incoming traffic from organizations that engage in this pracrice as a means to defer people from attempting this kind of IP takeover? As for my company, we take a fairly hard line on what IP blocks we allow inbound and therefore we block traffic from Russia, China, etc. because we have deemed our employees do not need to surf those sites while working. I have been debating since I read about the Media Breakaway story if for security reasons we should block their IP block as well. If they are willing to engage in this kind of practice, what else are they willing to do? ________________________________ From: arin-ppml-bounces at arin.net on behalf of Jon Lewis Sent: Thu 5/1/2008 11:51 AM To: Andrew Dul Cc: ppml at arin.net Subject: Re: [arin-ppml] 134.17.0.0/16 On Thu, 1 May 2008, Andrew Dul wrote: > http://blog.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html This is kind of old news, but it'll be very interesting to see how ARIN handles it, and if it ends up in court, how it's decided. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Thu May 1 13:51:44 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 1 May 2008 11:51:44 -0600 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: References: <20080501163003.2883.qmail@hoster908.com> Message-ID: <443de7ad0805011051qa4dfbe3xeab93f4ceba0507e@mail.gmail.com> On Thu, May 1, 2008 at 11:11 AM, Dylan Ebner wrote: > > > > Does ARIN have any kind of policy for recommendations to be made to it's > members for dealing with this kind of accused abuse? > Does ARIN recommend that other organizations block incomming traffic from > these "hijacked" IP blocks? > I am curious to what people's opinion is on this matter. Should the ARIN > community try to block incoming traffic from organizations that engage in > this pracrice as a means to defer people from attempting this kind of IP > takeover? I think you raise a great question and one that begs a couple more: What is the most efficient manner of tracking this type of squatting / hijacking? Is there a method efficient enough to make it realistically plausible to keep a running list? Is there an organization equipped to maintain such a list? If there are good answers to these questions then we could leverage such a routing blacklist against those who would operate on any current or future IP black market. I think this would be very beneficial to the community as a whole because as you note, most of the people who would use IP space inappropriately are using it for something inappropriate. ~Chris > > As for my company, we take a fairly hard line on what IP blocks we allow > inbound and therefore we block traffic from Russia, China, etc. because we > have deemed our employees do not need to surf those sites while working. I > have been debating since I read about the Media Breakaway story if for > security reasons we should block their IP block as well. If they are willing > to engage in this kind of practice, what else are they willing to do? > > > ________________________________ > From: arin-ppml-bounces at arin.net on behalf of Jon Lewis > Sent: Thu 5/1/2008 11:51 AM > To: Andrew Dul > Cc: ppml at arin.net > Subject: Re: [arin-ppml] 134.17.0.0/16 > > > > > > On Thu, 1 May 2008, Andrew Dul wrote: > > > > http://blog.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html > > This is kind of old news, but it'll be very interesting to see how ARIN > handles it, and if it ends up in court, how it's decided. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public > Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > > -- Chris Grundemann www.linkedin.com/in/cgrundemann From tabris at tabris.net Thu May 1 14:15:14 2008 From: tabris at tabris.net (tabris) Date: Thu, 01 May 2008 11:15:14 -0700 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: <443de7ad0805011051qa4dfbe3xeab93f4ceba0507e@mail.gmail.com> References: <20080501163003.2883.qmail@hoster908.com> <443de7ad0805011051qa4dfbe3xeab93f4ceba0507e@mail.gmail.com> Message-ID: <481A08B2.8010604@tabris.net> Chris Grundemann wrote: > On Thu, May 1, 2008 at 11:11 AM, Dylan Ebner wrote: > >> >> Does ARIN have any kind of policy for recommendations to be made to it's >> members for dealing with this kind of accused abuse? >> Does ARIN recommend that other organizations block incomming traffic from >> these "hijacked" IP blocks? >> I am curious to what people's opinion is on this matter. Should the ARIN >> community try to block incoming traffic from organizations that engage in >> this pracrice as a means to defer people from attempting this kind of IP >> takeover? >> > > I think you raise a great question and one that begs a couple more: > > What is the most efficient manner of tracking this type of squatting / > hijacking? > Is there a method efficient enough to make it realistically plausible > to keep a running list? > Is there an organization equipped to maintain such a list? > I believe there is one that already tries to, albeit they don't seem to list this particular prefix (maybe b/c it's not technically invalid). http://www.cymru.com/BGP/incon_asn_list.html > If there are good answers to these questions then we could leverage > such a routing blacklist against those who would operate on any > current or future IP black market. I think this would be very > beneficial to the community as a whole because as you note, most of > the people who would use IP space inappropriately are using it for > something inappropriate. > > ~Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cgrundemann at gmail.com Thu May 1 15:26:21 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 1 May 2008 13:26:21 -0600 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: <481A08B2.8010604@tabris.net> References: <20080501163003.2883.qmail@hoster908.com> <443de7ad0805011051qa4dfbe3xeab93f4ceba0507e@mail.gmail.com> <481A08B2.8010604@tabris.net> Message-ID: <443de7ad0805011226haf09813l7cca578f47579d89@mail.gmail.com> On Thu, May 1, 2008 at 12:15 PM, tabris wrote: > Chris Grundemann wrote: > > What is the most efficient manner of tracking this type of squatting / > > hijacking? > > Is there a method efficient enough to make it realistically plausible > > to keep a running list? > > Is there an organization equipped to maintain such a list? > > > I believe there is one that already tries to, albeit they don't seem to > list this particular prefix (maybe b/c it's not technically invalid). > > http://www.cymru.com/BGP/incon_asn_list.html > I think (anyone please feel free to correct me) that the Team Cymru BGP Inconsistent Origin ASN List is based on a given prefix being announced from multiple AS' at the same time. Not based on who /should/ be announcing it. So it is a good tool for identifying some hijacking but only in cases where the "real" holder is still advertising that space. In a situation like the one that allegedly exists with 134.17/16; the proper holder is not advertising the space and thus that method does not reveal anything (because there is only one origin AS advertised for that block). Bogon lists block space that should not be advertised at all. Lists like the one from Team Cymru help identify potential hijackings of advertised space. The gap is in blocks that are assigned (not bogon) but not advertised (by the proper holder / assignee). That is the area where my questions are focused. > > > If there are good answers to these questions then we could leverage > > such a routing blacklist against those who would operate on any > > current or future IP black market. I think this would be very > > beneficial to the community as a whole because as you note, most of > > the people who would use IP space inappropriately are using it for > > something inappropriate. > > > > ~Chris > > > -- Chris Grundemann www.linkedin.com/in/cgrundemann From danny at tcb.net Thu May 1 15:50:58 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 1 May 2008 13:50:58 -0600 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: References: <20080501163003.2883.qmail@hoster908.com> Message-ID: <960F9AEC-1444-406C-8DD8-943418B6A9EE@tcb.net> On May 1, 2008, at 11:11 AM, Dylan Ebner wrote: > Does ARIN have any kind of policy for recommendations to be made to > it's members for dealing with this kind of accused abuse? > Does ARIN recommend that other organizations block incomming traffic > from these "hijacked" IP blocks? > I am curious to what people's opinion is on this matter. Should the > ARIN community try to block incoming traffic from organizations that > engage in this pracrice as a means to defer people from attempting > this kind of IP takeover? > > As for my company, we take a fairly hard line on what IP blocks we > allow inbound and therefore we block traffic from Russia, China, > etc. because we have deemed our employees do not need to surf those > sites while working. I have been debating since I read about the > Media Breakaway story if for security reasons we should block their > IP block as well. If they are willing to engage in this kind of > practice, what else are they willing to do? I suspect at this point ARIN would steer well clear of making any type of operational recommendations to operators regarding these types of activities. Of course, the root issue here is that even if a prefix were hijacked, ARIN has no operational control over what's actually routed and what's not - although the work with RPKI and SIDR will change this, and those of you not paying attention might want to have a sniff. I would observe that if you're sending spam from blocks of legacy address space IN-ADDR functionality is important, and perhaps the only reason one might sign a legacy RSA, rather than just simply announcing the space and using it for whatever gives you your fix. Finally, in reviewing this the other day, I did find the text under Q2 here: "The fees charged are intended to maintain accurate account records, to prevent hijacking or unforward events, not burden the Legacy address holder" somewhat ambiguous, and well in need of some clarifying text - for obvious reasons. -danny From stephen at sprunk.org Thu May 1 16:21:42 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 1 May 2008 15:21:42 -0500 Subject: [arin-ppml] 134.17.0.0/16 References: <20080501163003.2883.qmail@hoster908.com> <960F9AEC-1444-406C-8DD8-943418B6A9EE@tcb.net> Message-ID: <009701c8abca$9108ddc0$563816ac@atlanta.polycom.com> Thus spake "Danny McPherson" > Finally, in reviewing this the other day, I did find the text > under Q2 here: > > > > "The fees charged are intended to maintain accurate account > records, to prevent hijacking or unforward events, not burden > the Legacy address holder" somewhat ambiguous, and well > in need of some clarifying text - for obvious reasons. Could you expand on what you'd like to see instead? The Q&A makes it very clear what the purpose of the LRSA is. A2 in particular makes it clear what the purpose of the fees are: to pay for maintaining accurate account records. That's why they're called "maintenance" fees. Non-RSA'd legacy space is easy to hijack because ARIN has no clear records or business relationship with the entity that supposedly controls it, so they have a difficult time proving that an entity trying to transfer that space to another party either is or is not the original legacy registrant. Trying to clean and maintain those records costs staff time, i.e. money. The maintenance fees pay for that. The fees also have a beneficial side effect of keeping the information current, since the billing process itself requires annual contact may prompt records changes, as the organization itself changes, that would otherwise be lost over time if there were no regular contact. Keep in mind that _over half_ of legacy records haven't been touched by their registrants since ARIN was formed over ten years ago. It's highly likely that most of those records are grossly incorrect due to M&A activity, bankrupcies, name changes, etc. The contact information is almost certainly incorrect. How is ARIN supposed to know if someone claiming to represent an organization that received its space 10-25 years ago is really the same entity? If you're one of those orgs, isn't it worth $100/yr to make sure nobody can hijack your (coveted) legacy space and get it marked as a spam haven? 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 From joe at via.net Thu May 1 16:43:52 2008 From: joe at via.net (joe mcguckin) Date: Thu, 1 May 2008 13:43:52 -0700 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: <009701c8abca$9108ddc0$563816ac@atlanta.polycom.com> References: <20080501163003.2883.qmail@hoster908.com> <960F9AEC-1444-406C-8DD8-943418B6A9EE@tcb.net> <009701c8abca$9108ddc0$563816ac@atlanta.polycom.com> Message-ID: <163064FD-779C-4B8C-83D4-CF78AF1F4E48@via.net> As the holder of legacy space, I'm willing to pay the $100/yr maintenence fee. It seems reasonable. I do object to the RSA which attempts to impose more restrictions on the space that what I originally agreed to. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On May 1, 2008, at 1:21 PM, Stephen Sprunk wrote: > Thus spake "Danny McPherson" >> Finally, in reviewing this the other day, I did find the text >> under Q2 here: >> >> >> >> "The fees charged are intended to maintain accurate account >> records, to prevent hijacking or unforward events, not burden >> the Legacy address holder" somewhat ambiguous, and well >> in need of some clarifying text - for obvious reasons. > > Could you expand on what you'd like to see instead? > > The Q&A makes it very clear what the purpose of the LRSA is. A2 in > particular makes it clear what the purpose of the fees are: to pay for > maintaining accurate account records. That's why they're called > "maintenance" fees. > > Non-RSA'd legacy space is easy to hijack because ARIN has no clear > records > or business relationship with the entity that supposedly controls > it, so > they have a difficult time proving that an entity trying to transfer > that > space to another party either is or is not the original legacy > registrant. > Trying to clean and maintain those records costs staff time, i.e. > money. > The maintenance fees pay for that. The fees also have a beneficial > side > effect of keeping the information current, since the billing process > itself > requires annual contact may prompt records changes, as the > organization > itself changes, that would otherwise be lost over time if there were > no > regular contact. > > Keep in mind that _over half_ of legacy records haven't been touched > by > their registrants since ARIN was formed over ten years ago. It's > highly > likely that most of those records are grossly incorrect due to M&A > activity, > bankrupcies, name changes, etc. The contact information is almost > certainly > incorrect. How is ARIN supposed to know if someone claiming to > represent an > organization that received its space 10-25 years ago is really the > same > entity? If you're one of those orgs, isn't it worth $100/yr to make > sure > nobody can hijack your (coveted) legacy space and get it marked as a > spam > haven? > > 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 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From paul at vix.com Thu May 1 16:50:03 2008 From: paul at vix.com (Paul Vixie) Date: Thu, 01 May 2008 20:50:03 +0000 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: Your message of "Thu, 01 May 2008 13:43:52 MST." <163064FD-779C-4B8C-83D4-CF78AF1F4E48@via.net> References: <20080501163003.2883.qmail@hoster908.com> <960F9AEC-1444-406C-8DD8-943418B6A9EE@tcb.net> <009701c8abca$9108ddc0$563816ac@atlanta.polycom.com> <163064FD-779C-4B8C-83D4-CF78AF1F4E48@via.net> Message-ID: <98499.1209675003@sa.vix.com> > As the holder of legacy space, I'm willing to pay the $100/yr maintenence > fee. It seems reasonable. I do object to the RSA which attempts to impose > more restrictions on the space that what I originally agreed to. as the president of a 501(c)(3) which holds legacy space, i saw LRSA as a good thing, it modernized an ancient relationship, it codified ISC's rights, and it took away no right that i thought ISC had. where did i go wrong, joe? From danny at tcb.net Thu May 1 16:51:23 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 1 May 2008 14:51:23 -0600 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: <009701c8abca$9108ddc0$563816ac@atlanta.polycom.com> References: <20080501163003.2883.qmail@hoster908.com> <960F9AEC-1444-406C-8DD8-943418B6A9EE@tcb.net> <009701c8abca$9108ddc0$563816ac@atlanta.polycom.com> Message-ID: <930B9583-ED7E-4791-B749-CD067522236B@tcb.net> On May 1, 2008, at 2:21 PM, Stephen Sprunk wrote: > > Could you expand on what you'd like to see instead? My issue here is the largely ambiguous use of the words "prevent" and "hijacking" in the text. I suppose if it's strictly in the context of allocations, that's fine, but folks might be easily confused and presume some operational "Internet routing" association (a nudge by one such person led me to review that text), which is clearly not the intention. That's all.... -danny From oberman at es.net Thu May 1 16:56:28 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 01 May 2008 13:56:28 -0700 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: Your message of "Thu, 01 May 2008 20:50:03 -0000." <98499.1209675003@sa.vix.com> Message-ID: <20080501205628.BA85B4501A@ptavv.es.net> > From: Paul Vixie > Date: Thu, 01 May 2008 20:50:03 +0000 > Sender: arin-ppml-bounces at arin.net > > > As the holder of legacy space, I'm willing to pay the $100/yr maintenence > > fee. It seems reasonable. I do object to the RSA which attempts to impose ^^^ > > more restrictions on the space that what I originally agreed to. > > as the president of a 501(c)(3) which holds legacy space, i saw LRSA as a ^^^^ > good thing, it modernized an ancient relationship, it codified ISC's rights, > and it took away no right that i thought ISC had. where did i go wrong, joe? I don't see the disagreement. Before the LRSA, there was only the RSA. LRSA != RSA. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From paul at vix.com Thu May 1 18:17:48 2008 From: paul at vix.com (Paul Vixie) Date: Thu, 01 May 2008 22:17:48 +0000 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: Your message of "Thu, 01 May 2008 13:56:28 MST." <20080501205628.BA85B4501A@ptavv.es.net> References: <20080501205628.BA85B4501A@ptavv.es.net> Message-ID: <17645.1209680268@sa.vix.com> > > > As the holder of legacy space, I'm willing to pay the $100/yr maintenence > > > fee. It seems reasonable. I do object to the RSA which attempts to impose > ^^^ > > > more restrictions on the space that what I originally agreed to. > > > > as the president of a 501(c)(3) which holds legacy space, i saw LRSA as a > ^^^^ > > good thing, it modernized an ancient relationship, it codified ISC's > > rights, and it took away no right that i thought ISC had. where did i go > > wrong, joe? > > I don't see the disagreement. Before the LRSA, there was only the RSA. > LRSA != RSA. the RSA wasn't applicable to legacy space, which is the subject of joe's words. From bmanning at vacation.karoshi.com Thu May 1 19:05:45 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 1 May 2008 23:05:45 +0000 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: <17645.1209680268@sa.vix.com> References: <20080501205628.BA85B4501A@ptavv.es.net> <17645.1209680268@sa.vix.com> Message-ID: <20080501230545.GB7634@vacation.karoshi.com.> On Thu, May 01, 2008 at 10:17:48PM +0000, Paul Vixie wrote: > > > > As the holder of legacy space, I'm willing to pay the $100/yr maintenence > > > > fee. It seems reasonable. I do object to the RSA which attempts to impose > > ^^^ > > > > more restrictions on the space that what I originally agreed to. > > > > > > as the president of a 501(c)(3) which holds legacy space, i saw LRSA as a > > ^^^^ > > > good thing, it modernized an ancient relationship, it codified ISC's > > > rights, and it took away no right that i thought ISC had. where did i go > > > wrong, joe? > > > > I don't see the disagreement. Before the LRSA, there was only the RSA. > > LRSA != RSA. > > the RSA wasn't applicable to legacy space, which is the subject of joe's words. > _______________________________________________ actually, a holder of legacy space could choose to place it under the current RSA, if they wanted to. the Legacy Service Agreement is exclusively for legacy space. --bill From joe at via.net Thu May 1 19:54:39 2008 From: joe at via.net (joe mcguckin) Date: Thu, 1 May 2008 16:54:39 -0700 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: References: <20080501163003.2883.qmail@hoster908.com> <960F9AEC-1444-406C-8DD8-943418B6A9EE@tcb.net> <009701c8abca$9108ddc0$563816ac@atlanta.polycom.com> <163064FD-779C-4B8C-83D4-CF78AF1F4E48@via.net> Message-ID: On May 1, 2008, at 2:28 PM, Owen DeLong wrote: > Just out of curiosity, which restrictions do you object to? From the ARIN website page dealing with Legacy Space: > Legacy RSA contractually locks in a set of rights, and thus reduces > the risk of future change to a minimum. I find this statement troublesome, since I don't necessarily agree that ARIN has any legal standing or authority to change any of the terms pertaining to legacy space I control. LRSA Agreement: > If Legacy Applicant fails to comply with the terms of this Legacy > Agreement, ARIN may terminate this Legacy Agreement > and refuse to provide the Services to Legacy Applicant. As it currently stands, I'm currently obligated to do nothing. If I do nothing, there's no penalty. If I sign the LRSA and fail to comply with any of the terms, ARIN could potentially rescind the space, as I understand the document. the term ?Services? may include, without limitation, ... and administration of IP address space related to number resources issued prior to ARIN?s inception on December 22, 1997 in its service area. IP address space and ASNs shall be defined as ?number resources. > (c) Cooperation. During the term of this Legacy Agreement, Legacy > Applicant shall provide ARIN > complete, up-to-date and accurate information, assistance, and > cooperation that ARIN requests in > ARIN?s provision of the Services to Legacy Applicant, including, > without limitation, during any review of > Legacy Applicant?s utilization of allocated number resources. If > Legacy Applicant does not provide > ARIN with required information, assistance, or cooperation that ARIN > requests, ARIN may: (i) take > such failure into account in determining Legacy Applicant?s future > allocation/assignment of additional number resources, and/or (ii) > terminate this Legacy Agreement. I'm not currently obligated to provide allocation info. Why the threat to terminate the agreement? I would think that failure to provide requested info would simply impact future allocations. > (d) Prohibited Conduct. This entire section should be removed. I don't think it's ARIN's mandate to enforce the ethical or legal behavior of its membership. > 6. FEES; PAYMENTS > (b) If Legacy Applicant does not pay the Annual Legacy > Maintenance Fee or other > fees that may be owed ARIN hereunder, ARIN shall provide written > notification to the Applicant > approximately thirty (30) days following the date on which the > payment is not made. If Legacy > Applicant fails to make payment in response to the notice of > delinquency, ARIN shall provide Legacy > Applicant with an additional written notice, by certified or > registered mail, return receipt requested, (as > appropriate in each country), and, when possible, by e-mail and > telephone. ARIN has the right to: (i) > revoke the included number resources if unpaid after 12 months of > the due date, and/or ARIN is > unable to contact the Applicant after 12 months > Once again, the threat of revoking my address space for non- payment of maintenence fees. > 9. NO PROPERTY RIGHTS This means that if ARIN screws something up, they're not liable. NetSol tried to hide behind a similar argument, and if I recall correctly, they lost. > 11. REPRESENTATIONS AND WARRANTIES > (b) By Legacy Applicant. Legacy Applicant hereby represents and > warrants to ARIN that during the > term of this Legacy Agreement: that Legacy Applicant will comply > with all applicable laws, rules, and > regulations in its use of the Services, including this Legacy > Agreement and the Policies. See above In general, I find fault with the concept that any termination of the agreement means ARIN immediately revokes the legacy resources. I think it would be better if a default or breach of contract simply caused the legacy resources to revert to their original state. I think you have to ask what is trying to be accomplished here. If ARIN merely wants to encourage legacy resource holders to bring their contact information up to date, then just give legacy holders the option of paying the maintenance fee without having to sign a punitive contract. This agreement as written obviously has a further agenda: to irrevocably place my legacy resources under many of the same constraints that are found in the regular RSA. This legacy RSA is all stick and no carrot. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Thu May 1 23:03:05 2008 From: paul at vix.com (Paul Vixie) Date: Fri, 02 May 2008 03:03:05 +0000 Subject: [arin-ppml] 134.17.0.0/16 In-Reply-To: Your message of "Thu, 01 May 2008 23:05:45 GMT." <20080501230545.GB7634@vacation.karoshi.com.> References: <20080501205628.BA85B4501A@ptavv.es.net> <17645.1209680268@sa.vix.com> <20080501230545.GB7634@vacation.karoshi.com.> Message-ID: <82351.1209697385@sa.vix.com> > > the RSA wasn't applicable to legacy space, which is the subject of joe's > > words. > > actually, a holder of legacy space could choose to place it > under the current RSA, if they wanted to. the Legacy Service > Agreement is exclusively for legacy space. maybe so, but that's not what we're talking about in this thread. From bjohnson at drtel.com Fri May 2 10:08:01 2008 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 2 May 2008 09:08:01 -0500 Subject: [arin-ppml] Legacy Space authority Message-ID: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> This is probably a dumb question, but who does have authority over legacy assignments? - Brian From michael.dillon at bt.com Fri May 2 10:47:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 2 May 2008 15:47:51 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> Message-ID: > This is probably a dumb question, but who does have authority > over legacy assignments? It's not so dumb. The situation is rather complex so it isn't easy to give a definitive answer nor is it easy to sort out who really has authority. It's like asking who has authority over you. At first you will probably tell me that you are an adult and nobody has authority over you. But what if you are walking down the street and a police officer orders you to turn around and leave the area? You no longer have authority to continue walking down the street. What if you are enjoying a meal in the restaurant when a firefighter bursts in and orders everyone to leave the building due to a gas leak down the street. You no longer have the authority to finish your meal. And what if you are on an airplane and the flight attendant orders you to sit down. Do you have the authority to continue standing? So far, if you think about it, you could probably identify the chain of authority that backs up these other people who are claiming authority over you, and you would probably accept that the circumstances above do describe a situation in which you have less than full authority over yourself. All of these situations have many years (sometimes centuries) of precedence which explain and support the claim. Then we come to IP addresses. There is clearly less time for any precedents to have been formed so fewer people are able to answer your question about legacy assignments. For instance, there is a concept called delegation. You may own some shares in a company and have the authority to cast one vote per share. But you can delegate this authority to another person and now they can cast the vote. So if some organization had authority over legacy allocations at the time they were made, did they delegate this authority to ARIN? Or, at the time the allocations were made, was the authority to make them delegated by a 3rd party (Department of Commerce), who then delegated that authority to ARIN? By now it should be clear that we are getting into legal territory where the nuances need to be carefully examined by people who have special knowledge of such things as "authority". This is a huge grey area, where we regularly see things decided one way, and then years later, redecided in a different way. Law is not simple, and it is usually never cut and dried. Is it illegal to kill someone? No, of course not. Any soldier who is on a battlefield and following the rules of engagement can kill again and again without breaking laws. --Michael Dillon From bjohnson at drtel.com Fri May 2 11:00:16 2008 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 2 May 2008 10:00:16 -0500 Subject: [arin-ppml] Legacy Space authority In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> Message-ID: <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> Before ARIN was allocating IP space, who was doing it. Was it ICANN? If so, can't ICANN delegate their authority to the RIRs to handle these allocations? - Brian From plzak at arin.net Fri May 2 11:26:36 2008 From: plzak at arin.net (Ray Plzak) Date: Fri, 2 May 2008 11:26:36 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> Message-ID: Before the RIRs it was the Internet Registry (IR) which was known as the DDN NIC (until 1993) and then the InterNIC (1993-1997) that allocated/assigned IP address space to ISPs and end users. All of the organizations that operated a version of the Internet Registry were doing so under a US government contract. ICANN arrived on the scene after the Internet Registry was supplanted by the RIRs and is not in this chain of succession. Ray > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Brian Johnson > Sent: Friday, May 02, 2008 11:00 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority > > > Before ARIN was allocating IP space, who was doing it. Was it ICANN? If > so, can't ICANN delegate their authority to the RIRs to handle these > allocations? > > - Brian > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if > you experience any issues. From jmaimon at chl.com Fri May 2 11:33:09 2008 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 02 May 2008 11:33:09 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> Message-ID: <481B3435.7060401@chl.com> Ray Plzak wrote: > Before the RIRs it was the Internet Registry (IR) which was known as the DDN NIC (until 1993) and then the InterNIC (1993-1997) that allocated/assigned IP address space to ISPs and end users. All of the organizations that operated a version of the Internet Registry were doing so under a US government contract. ICANN arrived on the scene after the Internet Registry was supplanted by the RIRs and is not in this chain of succession. > > Ray > That doesnt mean that entities connecting to the internet had any legal obligation to bind their conduct to those organization's decisions, even at that time. It simply was the only practical way to operate. From jmaimon at chl.com Fri May 2 11:41:29 2008 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 02 May 2008 11:41:29 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> Message-ID: <481B3629.4000308@chl.com> michael.dillon at bt.com wrote: >> This is probably a dumb question, but who does have authority >> over legacy assignments? > Then we come to IP addresses. There is clearly less time > for any precedents to have been formed so fewer people There is no authority over what IP addresses I can type into my equipment. > So if some > organization had authority over legacy allocations at the > time they were made, did they delegate this authority to > ARIN? Or, at the time the allocations were made, was the > authority to make them delegated by a 3rd party (Department > of Commerce), who then delegated that authority to ARIN? The authority the registries have comes directly from the entities who participate on an ongoing basis in creating the network of networks, called the Internet. Since they choose to participate in the Registry system, that is the sum total of the Registries authority. > > By now it should be clear that we are getting into legal territory The legal territory is only with regards to the contractual relationships formed by the registries or by the predecessors or successors in interest. > where the nuances need to be carefully examined by people who > have special knowledge of such things as "authority". Unless I missed something, there is pretty skimpy legal history concerning utilization of "non-registry" blessed IP addresses in whatever manner. You cant have your cake and eat it too. If it isnt property, it cant be owned, it can only be governed by contracted relationships. Furthermore, to stand up and declare it as property is fairly tough to swallow, as its just a series of numbers with no inherent value. The actual value is in the Internet's entities collective choice to route those numbers to the entity wishing to use them, enabling the entities effective use of those numbers on the Internet. This is usually without any contractual relationship involved beyond immediate upstreams or peers. To claim as personal property routing slots in tens of thousands of other network entities routers seems to be a bit of a stretch. After all, what legal recourse what random Arin "customer" have were some never affiliated with ARIN or any registry ever entity manage to have the Arin's customer prefix announced into BGP, originated from their own network? Tortious interference, perhaps. But ARIN has no contract or authority over that entity. Likely they would with the entities upstream and things would proceed in that direction. And what legal recourse would an ARIN customer have when network entities refuse to route those numbers to them? At this time, ARIN explicitly disavows any attempt to claim such authority. Perhaps in the US that wouldnt matter, ICANN or DOC would claim it as their own (illegal) authority, if they felt like it, and perhaps the US court system would enable that. Now I think the Registry system is just grand and want to see everybody continue along with the self produced and self governing system. But that doesnt give anybody property rights or contractual rights where none existed prior. Joe From bjohnson at drtel.com Fri May 2 13:26:50 2008 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 2 May 2008 12:26:50 -0500 Subject: [arin-ppml] Legacy Space authority In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan><29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> Message-ID: <29A54911243620478FF59F00EBB12F4701083E80@ex01.drtel.lan> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ray Plzak > Sent: Friday, May 02, 2008 10:27 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority > > Before the RIRs it was the Internet Registry (IR) which was known as > the DDN NIC (until 1993) and then the InterNIC (1993-1997) that > allocated/assigned IP address space to ISPs and end users. All of the > organizations that operated a version of the Internet Registry were > doing so under a US government contract. ICANN arrived on the scene > after the Internet Registry was supplanted by the RIRs and is not in > this chain of succession. > How does IANA fit into this? - Brian From michael.dillon at bt.com Fri May 2 13:37:26 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 2 May 2008 18:37:26 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <481B3629.4000308@chl.com> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <481B3629.4000308@chl.com> Message-ID: > Since they choose to participate in the Registry system, that > is the sum total of the Registries authority. > > > > > By now it should be clear that we are getting into legal territory > > The legal territory is only with regards to the contractual > relationships formed by the registries or by the predecessors > or successors in interest. In the real world, laws apply to all kinds of social relationships not just those which are based on contracts. In addition, the law's concept of a "contract" may be rather broader than that of a person who has no legal training. The point is that we can't figure it out ourselves, and any opinions that we may state on this list really do not play any part whatsoever in the decisions about what happens. The interpretation of the past is up to the lawyers, and may never be figured out because in two years, anyone who thinks that IPv4 addresses have any value on the public Internet, is going to be considered a crackpot. >From the trial runs done at various IETF/NANOG/ARIN meetings, it should be clear to everyone that IPv6 connectivity can be used to provide Internet access with the exception of some minor problem areas which are likely to be fixed within months. In two years, everyone will see that IPv6 is the way forward and there won't be any point in working out these esoteric issues. > > where the nuances need to be carefully examined by people who have > > special knowledge of such things as "authority". > > Unless I missed something, there is pretty skimpy legal > history concerning utilization of "non-registry" blessed IP > addresses in whatever manner. Lawyers never let the lack of specific history stop them from arguing on a subject. There is plenty of history of other things that might be argued to be analogous to IP address registrations. > You cant have your cake and eat it too. If it isnt property, > it cant be owned, it can only be governed by contracted relationships. Now you are making a legal argument and I am not a lawyer so I have no idea if you are speaking the truth, lying to me, or simply misinformed. I suspect that a lawyer could eloquently argue the point that non-property can be owned under some set of circumstances, that contracted relationships are not required, that contracts can be implied or come into being regardless of the actions of the parties involved, etc., etc. Not sure how any of this applies to IP addresses. > And what legal recourse would an ARIN customer have when > network entities refuse to route those numbers to them? In general, they would only have recourse to sue the network entities which contracted to route numbers to them and then refused to route a specific set of numbers. Of course, anyone can sue anyone and ARIN has already been dragged into court in an IP address ownership dispute. But if we leave grasping at straws out of the equation, I suspect that ARIN can evade legal liability by simply not ordering ISPs to route, or not route, any specific address block. And in all of this, we should be wary of leakage into the IPv6 future. If some legal rights regarding IPv4 addresses were to be changed from what we have now, then it is likely that the same rules will apply to IPv6 addresses. The IPv6 world really does not need to be hampered by outmoded IPv4 problems. --Michael Dillon From stephen at sprunk.org Fri May 2 14:25:36 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 2 May 2008 13:25:36 -0500 Subject: [arin-ppml] 134.17.0.0/16 References: <20080501163003.2883.qmail@hoster908.com><960F9AEC-1444-406C-8DD8-943418B6A9EE@tcb.net><009701c8abca$9108ddc0$563816ac@atlanta.polycom.com><163064FD-779C-4B8C-83D4-CF78AF1F4E48@via.net> Message-ID: <031f01c8ac84$36783fd0$563816ac@atlanta.polycom.com> Thus spake "joe mcguckin" > On May 1, 2008, at 2:28 PM, Owen DeLong wrote: >> Just out of curiosity, which restrictions do you object to? > > From the ARIN website page dealing with Legacy Space: > > Legacy RSA contractually locks in a set of rights, and thus > reduces the risk of future change to a minimum. > > I find this statement troublesome, since I don't necessarily > agree that ARIN has any legal standing or authority to change > any of the terms pertaining to legacy space I control. IMHO, you misunderstand your situation. You do not "control" anything except your own network. You're welcome to use any numbers you want on it, including (but not limited to) your legacy space. What ARIN (or any RIR) does is publish a directory of who has what and promises that there will be no duplication. Most orgs pay for the service of being listed in that directory. However, you are _not_ paying for that service; the community is presently providing that service to legacy holders for free because it is generally accepted as also providing a benefit to those who _are_ paying. ARIN is under no legal obligation I'm aware of, though, to continue doing so if the community adopts policy to the contrary or to not register the same space to other orgs. If you sign an RSA/LRSA, it would be. > LRSA Agreement: > > If Legacy Applicant fails to comply with the terms of this Legacy > Agreement, ARIN may terminate this Legacy Agreement > and refuse to provide the Services to Legacy Applicant. > > As it currently stands, I'm currently obligated to do nothing. If > I do nothing, there's no penalty. If I sign the LRSA and fail to > comply with any of the terms, ARIN could potentially rescind > the space, as I understand the document. There's no penalty for doing nothing _today_. An LRSA guarantees there'll be no penalty tomorrow, either, unless you don't comply with the terms, which aren't onerous and in fact more lenient than are given to those signing the normal RSA. The LRSA also exempts you from potential future policies that would conflict with the LRSA, which you may not be exempt from if you do not sign. You would also be free to switch to any future version of the LRSA (because, perhaps, it offers you better terms) or keep your existing version indefinitely, a power RSA signers definitely do not have. > the term ?Services? may include, without limitation, ... and > administration of IP address space related to number resources > issued prior to ARIN?s inception on December 22, 1997 in its > service area. IP address space and ASNs shall be defined > as ?number resources. > > (c) Cooperation. During the term of this Legacy Agreement, Legacy > Applicant shall provide ARIN complete, up-to-date and accurate > information, assistance, and cooperation that ARIN requests in > ARIN?s provision of the Services to Legacy Applicant, including, > without limitation, during any review of Legacy Applicant?s > utilization of allocated number resources. If Legacy Applicant does > not provide ARIN with required information, assistance, or > cooperation that ARIN requests, ARIN may: (i) take such failure > into account in determining Legacy Applicant?s future > allocation/assignment of additional number resources, and/or (ii) > terminate this Legacy Agreement. > > I'm not currently obligated to provide allocation info. Why the > threat to terminate the agreement? I would think that failure to > provide requested info would simply impact future allocations. If you're in breach of a contract, the usual remedy is for the other party to stop providing (or at least guaranteeing to provide) the services promised. In that case, your legacy space would revert to the (ambiguous) status it had prior to you signing the LRSA. Ditto if you choose not to renew your LRSA in the future. > (d) Prohibited Conduct. > > This entire section should be removed. I don't think it's ARIN's > mandate to enforce the ethical or legal behavior of its membership. All of the conduct prohibited is directly related to the services ARIN is promising to provide and their protection. You'll find similar clauses in any service provider's contract; the telephone company doesn't want you DDOSing their 911 center, or assisting others in doing so, either. If you have a problem agreeing to such terms, I don't think we have much to discuss... > 6. FEES; PAYMENTS > (b) If Legacy Applicant does not pay the Annual Legacy > Maintenance Fee or other fees that may be owed ARIN > hereunder, ARIN shall provide written notification to the Applicant > approximately thirty (30) days following the date on which the > payment is not made. If Legacy Applicant fails to make payment > in response to the notice of delinquency, ARIN shall provide > Legacy Applicant with an additional written notice, by certified > or registered mail, return receipt requested, (as appropriate in > each country), and, when possible, by e-mail and telephone. > ARIN has the right to: (i) revoke the included number resources > if unpaid after 12 months of the due date, and/or ARIN is > unable to contact the Applicant after 12 months > > Once again, the threat of revoking my address space for non- > payment of maintenence fees. Keep in mind that's only if you renew your agreement but refuse to pay for the services you promised to pay for. I'd prefer that only option (ii), which you snipped, was available to ARIN. Perhaps that'll be in the next revision. > 9. NO PROPERTY RIGHTS > > This means that if ARIN screws something up, they're not liable. > NetSol tried to hide behind a similar argument, and if I recall > correctly, they lost. Um, that's not what that section says. It says that numbers are not property and you agree not to assert claims they are. Since numbers can't be property (as courts have already ruled, in the case of the AACS LA trying to copyright 128-bit encryption keys), this is a no-brainer. > 11. REPRESENTATIONS AND WARRANTIES > (b) By Legacy Applicant. Legacy Applicant hereby represents and > warrants to ARIN that during the term of this Legacy Agreement: > that Legacy Applicant will comply with all applicable laws, rules, > and regulations in its use of the Services, including this Legacy > Agreement and the Policies. > > See above Again, what is your problem with agreeing not to break the law? Do you intend to do so? Is your counsel aware of that? > In general, I find fault with the concept that any termination of the > agreement means ARIN immediately revokes the legacy resources. > I think it would be better if a default or breach of contract simply > caused the legacy resources to revert to their original state. I agree. I would much prefer that termination always result in a return to the prior state, i.e. as if the LRSA had never been signed. > I think you have to ask what is trying to be accomplished here. If > ARIN merely wants to encourage legacy resource holders > to bring their contact information up to date, then just give legacy > holders the option of paying the maintenance fee without having to > sign a punitive contract. I'd prefer that the contract not be punitive, but it's hard to be paying for services without a contract at all. Any payment for services _implies_ a contract, and it's better to have it written down than have courts try to figure out what was implied at the time. > This agreement as written obviously has a further agenda: to > irrevocably place my legacy resources under many of the same > constraints that are found in the regular RSA. I disagree with your characterization of the intent. At most, the LRSA does not represent the intent as well as it could, since it was created by modifying the existing RSA instead of starting from scratch. > This legacy RSA is all stick and no carrot. There's a carrot there, but I agree there's also too much stick. 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 From plzak at arin.net Fri May 2 16:04:38 2008 From: plzak at arin.net (Ray Plzak) Date: Fri, 2 May 2008 16:04:38 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <29A54911243620478FF59F00EBB12F4701083E80@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan><29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E80@ex01.drtel.lan> Message-ID: The IANA function was performed by ISI under a USG contract until around 2000 when the contract was moved to ICANN where it still remains today. The IANA has primarily allocated address space to the Internet Registry (DDN NIC and InterNIC) and its successor, the RIRs. There were instances where there were separate large allocations made by Jon Postel to specific organizations during the Internet Registry period. Ray > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Brian Johnson > Sent: Friday, May 02, 2008 1:27 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > Behalf Of Ray Plzak > > Sent: Friday, May 02, 2008 10:27 AM > > To: ppml at arin.net > > Subject: Re: [arin-ppml] Legacy Space authority > > > > Before the RIRs it was the Internet Registry (IR) which was known as > > the DDN NIC (until 1993) and then the InterNIC (1993-1997) that > > allocated/assigned IP address space to ISPs and end users. All of the > > organizations that operated a version of the Internet Registry were > > doing so under a US government contract. ICANN arrived on the scene > > after the Internet Registry was supplanted by the RIRs and is not in > > this chain of succession. > > > > How does IANA fit into this? > > - Brian > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if > you experience any issues. From randy at psg.com Fri May 2 16:28:53 2008 From: randy at psg.com (Randy Bush) Date: Sat, 03 May 2008 05:28:53 +0900 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> Message-ID: <481B7985.8080508@psg.com> Brian Johnson wrote: > Before ARIN was allocating IP space, who was doing it. Was it ICANN? If > so, can't ICANN delegate their authority to the RIRs to handle these > allocations? the end user view: o first, dr. jon postel did both names and numbers informally o then he did them under government contract to isi and it became the iana o then sri nic did them under government contract, mostly done by ann westine [cooper] o then it was rebid, and saic won it and it became network solutions, mark and scott in a basement with a 56kb line. they quickly learned about scaling. :) this became verisign/netsol. o then the numbers were broken out and given to the rirs operating under the iana, one at a time as they were formed. arin was formed in '97. o it remains a simple hierarchy today, iana, rirs, isps/lirs, end sites today, with some tensions, some anomalies (see 'nir'), and a lot of bs. it is monitored by people in suits riding in black helicopters, and mailing list trolls. the former are not known to eat. do not feed the latter. randy From jmorrison at bogomips.com Fri May 2 16:38:30 2008 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 02 May 2008 13:38:30 -0700 Subject: [arin-ppml] Legacy Space authority In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <481B3629.4000308@chl.com> Message-ID: <481B7BC6.7040207@bogomips.com> michael.dillon at bt.com wrote: > The point is that we can't figure it out ourselves, and any opinions > that we may state on this list really do not play any part whatsoever > in the decisions about what happens. The interpretation of the past > is up to the lawyers, and may never be figured out because in two > years, anyone who thinks that IPv4 addresses have any value on the > public Internet, is going to be considered a crackpot. > > Am I the only person who's made a calendar entry for 2 years from now, so I could laugh at this again? Did I miss some flag day law being passed or a major carrier announcing that they were discontinuing support for IPv4? I think I'd expect to see some notice in advance that my ISP was going to stop delivering IPv4 to me. ("please remember to change the batteries in your smoke detectors, set your clocks back 1 hour, and disable IPv4 on all your Internet routers and servers...") Maybe I'm reading too much into your statement, but you're implicitly saying that IPv4 addresses will have NO value in two years. And it seems that for IPv4 addresses to have no value on the public Internet, it would have to be completely unusable on the public Internet. I'm quite sure that using *my* current IPv4 addresses, I could do a DNS lookup, get an A record in response, and connect using TCP to any well known web site, without any proxies or translations mangling things. Could someone else? Who knows, but that's going to be their problem in the future, not mine now. I'm sorry if it sounds cynical, but I just don't see vendors, ISPs, or businesses demanding that they or anybody else ready for IPv6 *now* for what might happen in two years. You'll probably just see proxies/caches/NATs being used to expand IPv4 address space, and anyone launching a new web service is going to need to find someone to host it on an IPv4 server, or their business is going to go bust, because they will be talking to a small crowd of IPv6 users, or only aiming at users in emerging markets/developing countries. From randy at psg.com Fri May 2 16:48:09 2008 From: randy at psg.com (Randy Bush) Date: Sat, 03 May 2008 05:48:09 +0900 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <481B7BC6.7040207@bogomips.com> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <481B3629.4000308@chl.com> <481B7BC6.7040207@bogomips.com> Message-ID: <481B7E09.9000406@psg.com> John Paul Morrison wrote: > michael.dillon at bt.com wrote: >> The point is that we can't figure it out ourselves, and any opinions >> that we may state on this list really do not play any part whatsoever >> in the decisions about what happens. The interpretation of the past >> is up to the lawyers, and may never be figured out because in two >> years, anyone who thinks that IPv4 addresses have any value on the >> public Internet, is going to be considered a crackpot. >> > Am I the only person who's made a calendar entry for 2 years from now, > so I could laugh at this again? > > Did I miss some flag day law being passed or a major carrier announcing > that they were discontinuing support for IPv4? have you not read? peano's postulates are being revoked 1 april 2010. end of internet numbers predicted. news at 11. randy From tedm at ipinc.net Fri May 2 17:24:27 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 2 May 2008 14:24:27 -0700 Subject: [arin-ppml] Legacy Space authority In-Reply-To: Message-ID: <011401c8ac9a$e6d6d880$6fce4b41@tedsdesk> > -----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: Friday, May 02, 2008 10:37 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority > > > > Since they choose to participate in the Registry system, that > > is the sum total of the Registries authority. > > > > > > > > By now it should be clear that we are getting into legal territory > > > > The legal territory is only with regards to the contractual > > relationships formed by the registries or by the predecessors > > or successors in interest. > > In the real world, laws apply to all kinds of social > relationships not just those which are based on contracts. In > addition, the law's concept of a "contract" may be rather > broader than that of a person who has no legal training. > > The point is that we can't figure it out ourselves, and any > opinions that we may state on this list really do not play > any part whatsoever in the decisions about what happens. That isn't true. Legal systems are based on history - for example who gave the owner of the property that your sitting on right now authority to own it? If you are in the United States, a large chunk of land has property rights based on purchase of it from France, and France based their right on "right of conquest" when they took it from the Indians - an action which was almost certainly a violation of the Indian's legal system (what there was of it, naturally) In short, from one point of view your sitting on illegally owned land. Here in the US we do not have active hot wars going on over the Louisiana Purchase, but they most definitely have them going on in the Mid East with regards to Israel's land ownership. Eventually one day the allocation of IP addresses is going to be formalized in a law somewhere in some government - and they will base that law on the precident that's being created right now by people doing what they are doing today - and that's being created partly by "opinions we may state on this list" > The > interpretation of the past is up to the lawyers, and may > never be figured out because in two years, anyone who thinks > that IPv4 addresses have any value on the public Internet, is > going to be considered a crackpot. > The inerpretation of most of the past is never "figured out" There are only multiple points of view. There are multiple competing points of view right now, today, as to what is going on in, for example, the Bush Presidency in the US - and 20 years from now, there will still be multiple points of view on what was going on in that administration. > >From the trial runs done at various IETF/NANOG/ARIN meetings, it > should be clear to everyone that IPv6 connectivity can be > used to provide Internet access with the exception of some minor > problem areas which are likely to be fixed within months. In > two years, everyone will see that IPv6 is the way forward and > there won't be any point in working out these esoteric issues. > People are still running MS-DOS and Windows 98. Never say never. > > > where the nuances need to be carefully examined by people who have > > > special knowledge of such things as "authority". > > > > Unless I missed something, there is pretty skimpy legal > > history concerning utilization of "non-registry" blessed IP > > addresses in whatever manner. > > Lawyers never let the lack of specific history stop them from > arguing on a subject. There is plenty of history of other > things that might be argued to be analogous to IP address > registrations. > > > You cant have your cake and eat it too. If it isnt property, > > it cant be owned, it can only be governed by contracted > relationships. > > Now you are making a legal argument and I am not a lawyer > so I have no idea if you are speaking the truth, lying > to me, or simply misinformed. I suspect that a lawyer > could eloquently argue the point that non-property can > be owned under some set of circumstances, They generally don't make that argument. They generally redefine non-property to be property. Saves a lot of time. > that contracted > relationships are not required, that contracts can be implied > or come into being regardless of the actions of the parties > involved, etc., etc. Not sure how any of this applies to IP addresses. > > > And what legal recourse would an ARIN customer have when > > network entities refuse to route those numbers to them? > > In general, they would only have recourse to sue the network > entities which contracted to route numbers to them and then > refused to route a specific set of numbers. Of course, anyone > can sue anyone and ARIN has already been dragged into court > in an IP address ownership dispute. But if we leave grasping > at straws out of the equation, I suspect that ARIN can evade > legal liability by simply not ordering ISPs to route, or not > route, any specific address block. > > And in all of this, we should be wary of leakage into the > IPv6 future. If some legal rights regarding IPv4 addresses > were to be changed from what we have now, then it is likely > that the same rules will apply to IPv6 addresses. The IPv6 > world really does not need to be hampered by outmoded IPv4 problems. > It already is. The entire IPv6 allocation system is based on how we do things with IPv4. One last rock I will toss - you said earlier a soldier on a battlefield could kill and kill again without breaking laws. That is also false. If this soldier is a member of the Catholic Church he cannot kill without breaking laws. (see 10 commandments) Also, that soldier is breaking the laws of the government of the people he is killing, and if he is caught and put into a POW camp by that government, they can torture him without breaking their laws. Just as the US tortured people recently without breaking US laws. And, just as the US killed many civilians by dropping atomic bombs on Japan without breaking laws during WWII. In short, the question "Is it illegal to kill someone" only has the right answer of "It depends on your point of view" With topics like killing, there's always a legal system somewhere that says such killing is illegal - even if done by a soldier within the rules of engagement - so "Of course not" is just as meaningless an answer as "absolutely yes" Ultimately, the question comes down to which legal system do you want to adopt - which is basically what this entire IPv4 discussion is all about. Ted From dean at av8.net Fri May 2 17:44:11 2008 From: dean at av8.net (Dean Anderson) Date: Fri, 2 May 2008 17:44:11 -0400 (EDT) Subject: [arin-ppml] Legacy Space authority (fwd) Message-ID: For some reason, this didn't go through. ---------- Forwarded message ---------- Date: Fri, 2 May 2008 15:43:35 -0400 (EDT) From: Dean Anderson To: Ray Plzak Cc: "ppml at arin.net" Subject: Re: [arin-ppml] Legacy Space authority On Fri, 2 May 2008, Ray Plzak wrote: > Before the RIRs it was the Internet Registry (IR) which was known as > the DDN NIC (until 1993) and then the InterNIC (1993-1997) that > allocated/assigned IP address space to ISPs and end users. All of the > organizations that operated a version of the Internet Registry were > doing so under a US government contract. ICANN arrived on the scene > after the Internet Registry was supplanted by the RIRs and is not in > this chain of succession. This statement about ICANN isn't entirely accurate. While it is true that ICANN was created after the RIRs, ICANN operates IANA, the government function that assigns IP address space. IANA precedes the RIRs and is the successor to DDN NIC and ARPA registry function. ICANN operates the US Government IANA function as a government contractor, just like SRI previously operated nic.ddn.mil (the DDN NIC). Legacy's got their space from the government. So did the RIRs. Those blocks are intangible property, just exactly like domain names. ARIN provides two functions: 1) It operates a portion of the government infrastructure function (whois and IN-ADDR) and holds the paper records which belong to the government. 2) ARIN has another function: the delegation of IP address space. In that function, it is sort of like the "ISP of last resort". The space delegated by the second function is the intangible property of ARIN, and those who recieve this delegated space don't get any property rights in that space. For Legacy's, ARIN is merely the registrar of deeds. Like the registrar of deeds that holds the records to the title of your house. Indeed, ARIN holds the paper records for legacys. When a legacy transfers its space, ARIN updates the records. ARIN does not own the legacy space. The Legacy RSA is an agreement that transfers ownership of legacy space to ARIN. The legacy dispute is almost entirely on the issue of intangible property rights. Some people assert (without proof) that ARIN can capriciously withhold its government obligations of operating whois service and IN-ADDR service to legacy's in order to coerce them into transfering their property to ARIN. However, since ARIN has no right to withhold these government services; the legal issue of the threat should be investigated. Attorney Richter is correct that ARIN has no authority over Legacy space. Whether the space is hijacked or not is unproven. Guilmette's article offers no proof of any allegation, but only innuendo. However, the hijacking of legacy space is a legitmate legal issue; If Richter has actually made false statements about the purchase of SF Packet Radio, he could be (and I think should be) disbarred. There are so far no evidence that the statements by Attorney Richter are false. One must consider the source of these claims of hijacking. Guilmette was previously the operator of the monkeys.org blacklist, which you may remember suddenly shutdown without announcement and blacklisted the entire internet, seriously disrupting the email of his customers who placed their trust in his good judgement and honesty. Also, you may find this demand letter from Verio interesting (http://www.monkeys.com/anti-spam/filtering/verio-demand.ps , and related to the veracity of these claims. In the letter, Verio demands that Guilmette remove an IP Address that Guilmette previously blacklisted. The demand arose after Guilmette apparently continued to refuse to remove the block well after Verio reported that the formmail.pl problem was fixed. A copy of the letter may be found at http://www.av8.net/verio-demand.ps, and a pdf conversion is at http://www.av8.net/verio-demand.pdf Guilmette associates with Alan Brown, Mathew Sullivan, and John Levine through the spam-l list. Brown is formerly the operator of ORBS.ORG, shut for defamation after making false claims about open relays to profit Brown's ISP, which was also lost in payment of damages). Matthew Sullivan is the ostensible operator SORBS.ORG with Paul Vixie and Dave Rand. SORBS.ORG was hosted by unelected ARIN Board Member Paul Vixie. Vixie denied hosting SORBS and transferred the service to his MAPS.ORG co-founder Dave Rand, but forgot to remove the in-addr.arpa entries. While denying involvement with SORBS, Vixie has curiously been willing to discuss the SORBS business model on ARIN-DISCUSS. ARIN-DISCUSS is the mailing list restricted to ARIN members for ARIN business, and it seems to be at least a conflict of interest for Board Members to promote their own business using ARIN resources. Levine is a business partner of Paul Vixie in a commercial bulk email operation called Whitehat. Full disclosure: SORBS.ORG also falsely and malicously claims that 198.3.136/21 and 130.105/16 are hijacked. Dean Anderson is the proper contact for both blocks, and has been for many years. These blocks are not hijacked and there is no reason to think they are or ever have been. I might also add that my participation in PPML and membership in ARIN was unlawfully interrupted in Feburary on the basis of false and fictional claims of per se defamation. ARIN staff or board members altered my statements to change their meaning, then falsely attributed the altered statement to me, and then falsely and fraudulently accused me of per se defamation, with the goal of having people rely on their false statements. One might assume that the CEO of ARIN (Ray Plzak) is either directly or ultimately responsible for the misconduct. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.net Fri May 2 17:44:36 2008 From: dean at av8.net (Dean Anderson) Date: Fri, 2 May 2008 17:44:36 -0400 (EDT) Subject: [arin-ppml] Correction: Re: Legacy Space authority (fwd) Message-ID: For some reason, this didn't go through. ---------- Forwarded message ---------- Date: Fri, 2 May 2008 16:05:47 -0400 (EDT) From: Dean Anderson To: Ray Plzak Cc: "ppml at arin.net" Subject: Correction: Re: [arin-ppml] Legacy Space authority Below I stated "SORBS.ORG was hosted by unelected ARIN Board Member Paul Vixie." This may be confusing. Paul Vixie's (and other Board Members) election is disputed due to lack of quorum (Vixie got only about 2% of the vote in an election that did not have the required 10% of the membership present and votable as required by law and bylaw). I apologize for any confusion. On Fri, 2 May 2008, Dean Anderson wrote: > On Fri, 2 May 2008, Ray Plzak wrote: > > > Before the RIRs it was the Internet Registry (IR) which was known as > > the DDN NIC (until 1993) and then the InterNIC (1993-1997) that > > allocated/assigned IP address space to ISPs and end users. All of the > > organizations that operated a version of the Internet Registry were > > doing so under a US government contract. ICANN arrived on the scene > > after the Internet Registry was supplanted by the RIRs and is not in > > this chain of succession. > > This statement about ICANN isn't entirely accurate. While it is true > that ICANN was created after the RIRs, ICANN operates IANA, the > government function that assigns IP address space. IANA precedes the > RIRs and is the successor to DDN NIC and ARPA registry function. ICANN > operates the US Government IANA function as a government contractor, > just like SRI previously operated nic.ddn.mil (the DDN NIC). > > Legacy's got their space from the government. So did the RIRs. Those > blocks are intangible property, just exactly like domain names. > > ARIN provides two functions: 1) It operates a portion of the government > infrastructure function (whois and IN-ADDR) and holds the paper records > which belong to the government. 2) ARIN has another function: the > delegation of IP address space. In that function, it is sort of like the > "ISP of last resort". The space delegated by the second function is the > intangible property of ARIN, and those who recieve this delegated space > don't get any property rights in that space. > > For Legacy's, ARIN is merely the registrar of deeds. Like the registrar > of deeds that holds the records to the title of your house. Indeed, ARIN > holds the paper records for legacys. When a legacy transfers its space, > ARIN updates the records. ARIN does not own the legacy space. The Legacy > RSA is an agreement that transfers ownership of legacy space to ARIN. > > The legacy dispute is almost entirely on the issue of intangible > property rights. Some people assert (without proof) that ARIN can > capriciously withhold its government obligations of operating whois > service and IN-ADDR service to legacy's in order to coerce them into > transfering their property to ARIN. However, since ARIN has no right to > withhold these government services; the legal issue of the threat should > be investigated. > > > Attorney Richter is correct that ARIN has no authority over Legacy > space. Whether the space is hijacked or not is unproven. Guilmette's > article offers no proof of any allegation, but only innuendo. However, > the hijacking of legacy space is a legitmate legal issue; If Richter has > actually made false statements about the purchase of SF Packet Radio, he > could be (and I think should be) disbarred. There are so far no evidence > that the statements by Attorney Richter are false. One must consider > the source of these claims of hijacking. > > Guilmette was previously the operator of the monkeys.org blacklist, > which you may remember suddenly shutdown without announcement and > blacklisted the entire internet, seriously disrupting the email of his > customers who placed their trust in his good judgement and honesty. > > Also, you may find this demand letter from Verio interesting > (http://www.monkeys.com/anti-spam/filtering/verio-demand.ps , and > related to the veracity of these claims. In the letter, Verio demands > that Guilmette remove an IP Address that Guilmette previously > blacklisted. The demand arose after Guilmette apparently continued to > refuse to remove the block well after Verio reported that the > formmail.pl problem was fixed. A copy of the letter may be found at > http://www.av8.net/verio-demand.ps, and a pdf conversion is at > http://www.av8.net/verio-demand.pdf > > Guilmette associates with Alan Brown, Mathew Sullivan, and John Levine > through the spam-l list. Brown is formerly the operator of ORBS.ORG, > shut for defamation after making false claims about open relays to > profit Brown's ISP, which was also lost in payment of damages). Matthew > Sullivan is the ostensible operator SORBS.ORG with Paul Vixie and Dave > Rand. SORBS.ORG was hosted by unelected ARIN Board Member Paul Vixie. > Vixie denied hosting SORBS and transferred the service to his MAPS.ORG > co-founder Dave Rand, but forgot to remove the in-addr.arpa entries. > While denying involvement with SORBS, Vixie has curiously been willing > to discuss the SORBS business model on ARIN-DISCUSS. ARIN-DISCUSS is > the mailing list restricted to ARIN members for ARIN business, and it > seems to be at least a conflict of interest for Board Members to promote > their own business using ARIN resources. Levine is a business partner > of Paul Vixie in a commercial bulk email operation called Whitehat. > > Full disclosure: SORBS.ORG also falsely and malicously claims that > 198.3.136/21 and 130.105/16 are hijacked. Dean Anderson is the proper > contact for both blocks, and has been for many years. These blocks are > not hijacked and there is no reason to think they are or ever have been. > > I might also add that my participation in PPML and membership in ARIN > was unlawfully interrupted in Feburary on the basis of false and > fictional claims of per se defamation. ARIN staff or board members > altered my statements to change their meaning, then falsely attributed > the altered statement to me, and then falsely and fraudulently accused > me of per se defamation, with the goal of having people rely on their > false statements. One might assume that the CEO of ARIN (Ray Plzak) is > either directly or ultimately responsible for the misconduct. > > --Dean > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From bicknell at ufp.org Fri May 2 17:57:52 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 May 2008 17:57:52 -0400 Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: References: Message-ID: <20080502215751.GA97286@ussenterprise.ufp.org> In a message written on Fri, May 02, 2008 at 05:44:11PM -0400, Dean Anderson wrote: > Legacy's got their space from the government. So did the RIRs. Those > blocks are intangible property, just exactly like domain names. There was a time when you could get a domain name by sending off an e-mail, much like early legacy assignments. Somewhere along the line a contract was imposed, fees were established, and a UDRP was created. As far as I know unless you agreed and started to pay the fees your domain name was dropped from the system. If Legacy blocks are "just exactly like domain names" then I would assume you feel the same could happen with legacy blocks. A contract could be imposed, fees established, and a dispute procedure created. I suppose the only sticking point is who, ARIN, IANA, ICANN, US Government? -- 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: 187 bytes Desc: not available URL: From mysidia at gmail.com Fri May 2 19:29:21 2008 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 02 May 2008 18:29:21 -0500 Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: <20080502215751.GA97286@ussenterprise.ufp.org> References: <20080502215751.GA97286@ussenterprise.ufp.org> Message-ID: <481BA3D1.1010701@gmail.com> Agreed, the same would have a basis for happening, and the block could later become assigned to another org later... Just as with domain registrations, there was never as much as a written promise that the assignment is meaningful and permanent forever, and on any network. There has been some argument that the assignments by the legacy registry were "transfers of property" instead of merely assignment of numbers to go with a named network. There has been no proof shown that the assignment is a "transfer" of property any more than registration of domain names were. Just like the registration of "port 25" to the SMTP protocol or the assignment of "port 201" to Appletalk is anybody's property; it doesn't matter whether you created the protocol, use it, etc... Your equipment is your property, but the registration itself is the property of whichever organization operates the registry. The current maintainer of the online registry _could_ in fact revoke that assignment, but it doesn't necessarily mean the community will stop using those port numbers. Nor does an IP registry de-listing a legacy registration necessarily indicate the community will stop routing those IPs to the same place. So it may not be a good thing to do: except in the extroardinary circumstance (which may eventually happen) that previously assigned expired space is the only space left to assign for new allocations, as the new registrant paying for maintenance of the registry might now have an ip block that is difficult or impossible for them to use without being disrupted by legacy networks still trying to use the space that is no longer assigned by the registry to that legacy network. Pulling domains is much easier... because the registrar can remove the domain's nameservers from the TLD zone, causing the domain to very quickly be inoperative. The only immediate thing the IP registries appear to have available to pull is IN-ADDR delegation -- which is a service of the registry. But that might be good enough, in the respect that it makes legacy space hijacking by spammers (relying on inaccurate org information) less-likely: no good reverse zone means the spammer will have a harder time getting their mail accepted. -- -J Leo Bicknell wrote: > In a message written on Fri, May 02, 2008 at 05:44:11PM -0400, Dean Anderson wrote: > >> Legacy's got their space from the government. So did the RIRs. Those >> blocks are intangible property, just exactly like domain names. >> > > There was a time when you could get a domain name by sending off > an e-mail, much like early legacy assignments. Somewhere along the > line a contract was imposed, fees were established, and a UDRP was > created. As far as I know unless you agreed and started to pay the > fees your domain name was dropped from the system. > > If Legacy blocks are "just exactly like domain names" then I would > assume you feel the same could happen with legacy blocks. A contract > could be imposed, fees established, and a dispute procedure created. > > I suppose the only sticking point is who, ARIN, IANA, ICANN, US > Government? > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From tedm at ipinc.net Fri May 2 20:11:42 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 2 May 2008 17:11:42 -0700 Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: Message-ID: <012601c8acb2$4423c450$6fce4b41@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dean Anderson > Sent: Friday, May 02, 2008 2:44 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority (fwd) > > > For some reason, this didn't go through. > > ---------- Forwarded message ---------- > Date: Fri, 2 May 2008 15:43:35 -0400 (EDT) > From: Dean Anderson > To: Ray Plzak > Cc: "ppml at arin.net" > Subject: Re: [arin-ppml] Legacy Space authority > > On Fri, 2 May 2008, Ray Plzak wrote: > > > Before the RIRs it was the Internet Registry (IR) which was > known as > > the DDN NIC (until 1993) and then the InterNIC (1993-1997) that > > allocated/assigned IP address space to ISPs and end users. > All of the > > organizations that operated a version of the Internet Registry were > > doing so under a US government contract. ICANN arrived on the scene > > after the Internet Registry was supplanted by the RIRs and > is not in > > this chain of succession. > > This statement about ICANN isn't entirely accurate. While it > is true that ICANN was created after the RIRs, ICANN operates > IANA, the government function that assigns IP address space. > IANA precedes the RIRs and is the successor to DDN NIC and > ARPA registry function. ICANN operates the US Government > IANA function as a government contractor, just like SRI > previously operated nic.ddn.mil (the DDN NIC). > > Legacy's got their space from the government. So did the RIRs. Those > blocks are intangible property, just exactly like domain names. > You can't know this unless you have a copy of the contract between the RIR's and IANA which as far as I know has not been made public. I would assume that there's a clause in it that specifies to the RIR getting the /8 from IANA that the address is NOT property, similar to the clause in the contract that an IP requester signs from the RIR that states IP address is not property. In any case, US laws are NOT universally recognized by all governments in the world, including some governments that ARE on the Internet. Thus so far WIPO has not involved itself in address block assignments and until such time as it does, IF it does, this legacy argument (that legacy addresses are property) is confined to the United States. > ARIN provides two functions: 1) It operates a portion of the > government infrastructure function (whois and IN-ADDR) and > holds the paper records which belong to the government. 2) > ARIN has another function: the delegation of IP address > space. In that function, it is sort of like the "ISP of last > resort". The space delegated by the second function is the > intangible property of ARIN, and those who recieve this > delegated space don't get any property rights in that space. > > For Legacy's, ARIN is merely the registrar of deeds. Like > the registrar of deeds that holds the records to the title of > your house. Indeed, ARIN holds the paper records for legacys. > When a legacy transfers its space, ARIN updates the records. > ARIN does not own the legacy space. The Legacy RSA is an > agreement that transfers ownership of legacy space to ARIN. > > The legacy dispute is almost entirely on the issue of > intangible property rights. Some people assert (without > proof) that ARIN can capriciously withhold its government > obligations of operating whois service and IN-ADDR service to > legacy's in order to coerce them into transfering their > property to ARIN. ARIN has stated this on this mailing list, that is, ARIN's legal council has as I recall. Yes, this is nothing more than a claim. Until such time that YOUR assertion that ARIN cannot withhold whois and IN-ADDR services from legacies is tested in a court of law, your wild-assed assertions that ARIN has no control over whois for legacies is nothing more than a claim. I'll stake ARIN's claim that it CAN withhold whois against your claim that it cannot, any day. In fact I'd like to see you put your money where your mouth is and test this in a court so that this would be settled - until such time as you do so, please shut up. > However, since ARIN has no right to > withhold these government services; the legal issue of the > threat should be investigated. > > > Attorney Richter is correct that ARIN has no authority over > Legacy space. Whether the space is hijacked or not is > unproven. Guilmette's article offers no proof of any > allegation, but only innuendo. However, the hijacking of > legacy space is a legitmate legal issue; If Richter has > actually made false statements about the purchase of SF > Packet Radio, he could be (and I think should be) disbarred. > There are so far no evidence that the statements by Attorney > Richter are false. One must consider the source of these > claims of hijacking. > > Guilmette was previously the operator of the monkeys.org > blacklist, which you may remember suddenly shutdown without > announcement and blacklisted the entire internet, seriously > disrupting the email of his customers who placed their trust > in his good judgement and honesty. > > Also, you may find this demand letter from Verio interesting > (http://www.monkeys.com/anti-spam/filtering/verio-demand.ps , > and related to the veracity of these claims. In the letter, > Verio demands that Guilmette remove an IP Address that > Guilmette previously blacklisted. The demand arose after > Guilmette apparently continued to refuse to remove the block > well after Verio reported that the formmail.pl problem was > fixed. A copy of the letter may be found at > http://www.av8.net/verio-demand.ps, and a pdf conversion is > at http://www.av8.net/verio-demand.pdf > > Guilmette associates with Alan Brown, Mathew Sullivan, and > John Levine through the spam-l list. Brown is formerly the > operator of ORBS.ORG, shut for defamation after making false > claims about open relays to profit Brown's ISP, which was > also lost in payment of damages). Matthew Sullivan is the > ostensible operator SORBS.ORG with Paul Vixie and Dave Rand. > SORBS.ORG was hosted by unelected ARIN Board Member Paul Vixie. > Vixie denied hosting SORBS and transferred the service to his > MAPS.ORG co-founder Dave Rand, but forgot to remove the > in-addr.arpa entries. > While denying involvement with SORBS, Vixie has curiously > been willing to discuss the SORBS business model on > ARIN-DISCUSS. ARIN-DISCUSS is the mailing list restricted to > ARIN members for ARIN business, and it seems to be at least a > conflict of interest for Board Members to promote their own > business using ARIN resources. Levine is a business partner > of Paul Vixie in a commercial bulk email operation called Whitehat. > > Full disclosure: SORBS.ORG also falsely and malicously claims > that 198.3.136/21 and 130.105/16 are hijacked. Dean Anderson > is the proper contact for both blocks, and has been for many > years. These blocks are not hijacked and there is no reason > to think they are or ever have been. > We are not stupid, and can use Google and whois, Dean. 130.105/16 lists Open Software Foundation, not you, as the owner. You have been told REPEATEDLY by SORBS that all that is required to remove 130.105/16 from SORBS is a copy of a letter from the OSF stating that they gave you the netspace. (that would be The Open Group today, as OSF merged with X/Open to form that) If your use of that netblock is above board I cannot see the difficulty in that. Perhaps you could have your lawyer send a -politely- worded letter to them requesting this, and actually get some useful work out of the fees you have been paying him all these years. If you are the correct contact for 130.105/16 then why don't you change the name on the block with ARIN? The only logical answer I can see is that ARIN considers it hijacked. In any case, why you even care about what SORBS is doing is a mystery. How long has it been that they have blacklisted that block? Nearly a decade. One would think that any customers you have on that block who couldn't tolerate this would have left a long time ago, and the customers you have on that block don't care that SORBS has it blacklisted. > I might also add that my participation in PPML and membership > in ARIN was unlawfully interrupted in Feburary on the basis > of false and fictional claims of per se defamation. Yep, I remember that although it seems it was for off-topic posting not for that. > ARIN > staff or board members altered my statements to change their > meaning, Nope, I don't remember that happening. > then falsely attributed the altered statement to me, > and then falsely and fraudulently accused me of per se > defamation, with the goal of having people rely on their > false statements. One might assume that the CEO of ARIN (Ray > Plzak) is either directly or ultimately responsible for the > misconduct. > Please, please, please Dean, please sue ARIN. The resulting counter-suit once your rediculous statements have been rejected by the court will surely bankrupt you and you will have to sell your computer to pay the rent, then we will be rid of this silliness. Ted From tedm at ipinc.net Fri May 2 20:29:01 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 2 May 2008 17:29:01 -0700 Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: <481BA3D1.1010701@gmail.com> Message-ID: <012a01c8acb4$af5bd120$6fce4b41@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jimmy Hess > Sent: Friday, May 02, 2008 4:29 PM > To: Leo Bicknell; ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority (fwd) > > > Agreed, the same would have a basis for happening, and the > block could > later become assigned > to another org later... > Just as with domain registrations, there was never as much as > a written > promise that the assignment > is meaningful and permanent forever, and on any network. > I am not so sure of that. Perhaps no legally binding contract, but I think that there were e-mails and such that implied this. In any case, the real issue is that almost certainly there were verbal commitments to support whois on the legacy blocks. The whois data on the legacy blocks didn't enter itself. Just because ARIN may have the legal right to ignore a legacy assignment does not mean that this is the honorable thing to do. If IPv6 didn't exist then it would be incumbent on the Internet community to clean house of unused and orphaned assignments as well as hijacked assignments, and then the legal right to deal harshly with the legacy holders would be of far more importance. But it does. Therefore, it is not to the Internet communities advantage to stir up trouble by revoking old IPv4 assignments. As long as ARIN ignores the legacy holders and continues supporting whois, the legacy holders have no damages to themselves by ARIN thus no grounds to sue ARIN and possibly get lucky with some moron boneheaded judge who would upset the applecart by creating caselaw regarding IP addressing. > > There has been some argument that the assignments by the > legacy registry > were "transfers of property" > instead of merely assignment of numbers to go with a named network. > > There has been no proof shown that the assignment is a "transfer" of > property any more than registration > of domain names were. > > Just like the registration of "port 25" to the SMTP protocol or the > assignment of "port 201" to Appletalk > is anybody's property; it doesn't matter whether you created the > protocol, use it, etc... > Your equipment is your property, but the registration itself is the > property of whichever organization operates > the registry. > > The current maintainer of the online registry _could_ in fact revoke > that assignment, but it doesn't necessarily > mean the community will stop using those port numbers. > > Nor does an IP registry de-listing a legacy registration necessarily > indicate the community will stop routing > those IPs to the same place. > > > > > So it may not be a good thing to do: except in the extroardinary > circumstance (which may eventually happen) > that previously assigned expired space is the only space > left to assign for new allocations, as the new registrant > paying for > maintenance of the registry might now > have an ip block that is difficult or impossible for them to use > without being disrupted by legacy > networks still trying to use the space that is no longer > assigned by the > registry to that legacy network. > As long as the RIR's are still assigning IPv4 people will not switch to IPv6. As long as Microsoft still sells XP people will not switch to Vista. The parallels are obvious. It is clearly not to the Internet community's advantage to continue spending time on IPv4 once all operating systems and all routers in use on the Internet can support IPv6 - which is very close. Once we get rid of the last of the Win98, Win ME, Win 2K, and MacOS 9 systems on the Internet - and that date is rushing towards us faster and faster every day - then the devices on the Internet will be able to support IPv6 - and not using IPv6 after that date will merely be a choice, not dictated by any technical limitation. Ted From mysidia at gmail.com Fri May 2 21:06:58 2008 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 02 May 2008 20:06:58 -0500 Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: <012a01c8acb4$af5bd120$6fce4b41@tedsdesk> References: <012a01c8acb4$af5bd120$6fce4b41@tedsdesk> Message-ID: <481BBAB2.3020400@gmail.com> Ted Mittelstaedt wrote: >> ARIN clearly has moral obligations to ensure the legacy registrants can maintain their registrations. It's not clear that ARIN has to do this for free in perpetuity, or without requiring legacy registrants to eventually sign the RSA, however. And _now_ may not be a proper time to force the issue. I.E. I think for now, ARIN should wait, and strongly encourage legacy networks to update information and sign a Legacy RSA, and nothing more. I would think that giving the legacy networks the opportunity to maintain their registration under the same terms as other conventional registrants would effectively fulfill their obligation to maintain the services of the legacy registry, even if the only other option offered is "not to be registered". I.E. If the legacy registration failed to be maintained, it would be solely through the fault of the legacy network failing to stay in contact with the registry, provide current contact information, and follow the rules. Even if you think IP addresses are intangible property; there is still the need to maintain contact, otherwise the IP space is abandoned property, to be turned over to the state/government, if the contact information is invalid, and no contact is made for a sufficient duration. But I believe ARIN doesn't turn over abandoned IP addresses, as (1) it takes the position that IPs aren't property, and (2) Being an internet registry doesn't mean you are in the care of property. > As long as the RIR's are still assigning IPv4 people will not > switch to IPv6. > I'm not sure cessation of IPv4 assignments will cause that many to switch to IPv6 who wouldn't otherwise. > Once we get rid of the last of the Win98, Win ME, Win 2K, > and MacOS 9 systems on the Internet - and that date is rushing > towards us faster and faster every day - then the devices on > the Internet will be able to support IPv6 - and not using IPv6 > after that date will merely be a choice, not dictated by any > technical limitation. > Well, the OSes may support IPv6. This says nothing about the legacy software that may run on these computers. Just because your OS is new and IPv6-enabled, does not mean, that, for example, all the network-aware software you utilize can work with IPv6. I'm afraid there will be many sorts of communications software (I.E. online game software) that utilize IPs, and are no longer maintained or won't ever be adapted for IPv6. If the specialized software products are important enough, their users will be locked into IPv4. -- -J From paul at vix.com Sat May 3 12:22:49 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 03 May 2008 16:22:49 +0000 Subject: [arin-ppml] fair warning: less than 1000 days left to IPv4 exhaustion Message-ID: <70031.1209831769@sa.vix.com> from nanog, which means most ppml'ers have seen it, but some not. there was the usual set of responses from the usual people, mostly sarcastic. re: -------------- next part -------------- An embedded message was scrubbed... From: mleber at he.net (Mike Leber) Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion Date: Fri, 2 May 2008 11:51:43 -0700 (PDT) Size: 4117 URL: From dean at av8.net Sat May 3 13:27:10 2008 From: dean at av8.net (Dean Anderson) Date: Sat, 3 May 2008 13:27:10 -0400 (EDT) Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: <20080502215751.GA97286@ussenterprise.ufp.org> Message-ID: On Fri, 2 May 2008, Leo Bicknell wrote: > In a message written on Fri, May 02, 2008 at 05:44:11PM -0400, Dean Anderson wrote: > > Legacy's got their space from the government. So did the RIRs. Those > > blocks are intangible property, just exactly like domain names. > > There was a time when you could get a domain name by sending off > an e-mail, much like early legacy assignments. Somewhere along the > line a contract was imposed, fees were established, and a UDRP was > created. As far as I know unless you agreed and started to pay the > fees your domain name was dropped from the system. > > If Legacy blocks are "just exactly like domain names" then I would > assume you feel the same could happen with legacy blocks. A contract > could be imposed, fees established, and a dispute procedure created. I think that every legacy would agree to pay a small fee for the record services, especially when changes are made to the records. The local county registrar of deeds also charges fees to change the records on titles. I don't think anyone has ever had any objection to that. But this isn't about money. BTW, ARIN is asking in the Legacy RSA to pay $100 per year. This is a trivial amount, but still several times what people pay for domain names, which consume exactly the same effort by the registry maintaining the records. The objection is to the coercion on the improper threat of withholding infrastructure services and the improper transfer of ownership interest. The object of the coercion is not money or fair fees, but rather the transfer of legacy ownership interest in that IP Address space to ARIN; perhaps so that ARIN can give it to their NANOG pals in just 2 hours. ARIN has sent 22 employees over 100 times to NANOG, up to NANOG 41. What are the consequences of sending 22 employees, whose jobs have nothing to with network operations, to NANOG over 100 times? (including the ARIN executive secretary) One consequence is that about $50,000 of ARIN funds is transferred to NANOG, in addition to the $50,000 per year authorized by the (conflicted) ARIN Board of Directors. NANOG is a very small group of a couple hundred core members, and ARIN is paying a third or more of its annual budget. Yet, somehow NANOG members have taken control of all the ARIN directors slots with only about 2% of the membership voting for any Board Member. Those board members have been improperly using that influence to send large amounts of ARIN's money to NANOG. And they have also improperly silenced dissent by interfering with membership rights in ARIN. It seems unlikely that an ARIN Board that wasn't controlled by NANOG members would engage in activities that about 80% the ARIN membership don't engage in. Another consequence is that the ARIN employees make personal relationships that can be exploited to make resource assignments unfairly and unethically. At the last NANOG meeting (42), Sue Dobert, Erika Goedrich, and Mark Kosters attended from ARIN. Sue Dobert is a resource analyst who shouldn't have personal relationships with the persons applying for IP Address Space. Her job has nothing to do with actual network operations. She doesn't need to know how to configure BGP. Resource analysts make resource allocation decisions based on ARIN policy rules, and should be barred from attending such events because they create personal relations with ethical conflicts. NANOG is a junket for Erika Goedrich, membership coordinator: NANOG widely advertises and exploits its association with ARIN. One wonders just how many ARIN members were signed up, since it seems that nearly all the NANOG members are already voting for ARIN Board Members. NANOG is a junket for Mark Kosters, unless he was speaking, which according to the agenda, he wasn't. All 6 board members have conflicts of interest with NANOG; Even Scott Bradner, whom I previously had a great deal of respect for, hasn't responded to a question about whether he has was compensated in any way for his 3 speaking engagements at NANOG and whether or not he has a conflict of interest. Incidentally, the people that are making the attacks on me, on legacy space, and on the opposition to the Legacy RSA are also associated with NANOG, rather than a representative sample of the ARIN membership. The vast majority of ARIN members don't participate in NANOG. To be clear, I've got no problem with sending speakers to NANOG, or anywhere that pays ARIN for the speaker to come. I do have a problem with the overly cozy breaking down of ethical barriers, particularly with an organization that doesn't repudiate thugish threats of violence. I've got a issue with NANOG (a small group of a couple hundred core people) taking control of ARIN in dubious elections, and then taking large amounts of ARIN money, then creating unethical conditions for resource allocations, and then trying to take control of Legacy IP Address space by improper threats. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From paul at vix.com Sat May 3 13:49:09 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 03 May 2008 17:49:09 +0000 Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: Your message of "Fri, 02 May 2008 17:44:11 -0400." References: Message-ID: <71981.1209836949@sa.vix.com> for the record, then: > ... > Guilmette associates with Alan Brown, Mathew Sullivan, and John Levine > through the spam-l list. Brown is formerly the operator of ORBS.ORG, > shut for defamation after making false claims about open relays to > profit Brown's ISP, which was also lost in payment of damages). Matthew > Sullivan is the ostensible operator SORBS.ORG with Paul Vixie and Dave > Rand. SORBS.ORG was hosted by unelected ARIN Board Member Paul Vixie. > Vixie denied hosting SORBS and transferred the service to his MAPS.ORG > co-founder Dave Rand, but forgot to remove the in-addr.arpa entries. > While denying involvement with SORBS, Vixie has curiously been willing > to discuss the SORBS business model on ARIN-DISCUSS. ARIN-DISCUSS is > the mailing list restricted to ARIN members for ARIN business, and it > seems to be at least a conflict of interest for Board Members to promote > their own business using ARIN resources. Levine is a business partner > of Paul Vixie in a commercial bulk email operation called Whitehat. > ... for the record, it isn't december of an odd numbered year, and so, i won't be disputing, refuting, explaining, arguing, or discussing in detail any of dean anderson's statements about me or my activities. a man's got to know his limitations. one weekend out of 100, i will worry about what onlookers might think of dean's repeated accusations of malfeasance against me. this isn't the one. i know i used to give more than 1%, but it was way too much. From michael.dillon at bt.com Sat May 3 18:28:09 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 3 May 2008 23:28:09 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <481B7BC6.7040207@bogomips.com> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan><481B3629.4000308@chl.com> <481B7BC6.7040207@bogomips.com> Message-ID: > > The interpretation of > the past is > > up to the lawyers, and may never be figured out because in > two years, > > anyone who thinks that IPv4 addresses have any value on the public > > Internet, is going to be considered a crackpot. > > > > > Am I the only person who's made a calendar entry for 2 years > from now, so I could laugh at this again? > > Did I miss some flag day law being passed or a major carrier > announcing that they were discontinuing support for IPv4? The key date is not when IPv4 is discontinued. It is when IPv6 *BEGINS* to be used for general Internet services, i.e. the various gateway issues such as NAT-PT are pretty much solved. That date is highly likely to coincide with the time, about two years from now, when the well publicised runout of the global free pool of IPv4 addresses happens. After all, if at least one company can make a business out of selling Internet access over IPv6, then it is abundantly clear, even at the CEO level, that hanging on to IPv4 numbers is no more than a short term insurance plan for the transition to IPv6. IPv4 addresses cease to be valuable on the public Internet, and are only valued for internal network uses. This is when some ISPs will begin transitioning access customers to IPv6 in order to free up IPv4 addresses for expansion of their MPLS or v6-over-v4 core networks, or for expanding their management systems. These are all slow growth areas where there is some leeway in deployment decisions that you don't have on the access side. > I think I'd expect to see some notice in advance that my ISP > was going to stop delivering IPv4 to me. So would I. This is something that should appear in renewal contracts any time now, if not already. Of course, existing IPv4 connections will not stop working, but any contracts that allow for adding sites, or expanding the size of a connection for more end users (with more addresses) are going to be reworded a bit. End user companies who absolutely, positively want to guarantee that they can add sites to their IPv4 VPNs in 3, 4, 5 years from now, are going to be adding special language to their contracts. And to cover that, ISPs will change other contracts so that they can back out without penalties if sufficient IPv4 addresses are not available. In two to three years, every network operator is going to start cannibalizing their own network, cutting off some IPv4 customers in order to recover IPv4 addresses for their most valued and profitable customers. End user companies can ride out the chaos of IPv4 runout simply by getting their contracts right. But all ISPs will have to deal with IPv6 and at minimum, make sure that they can provide a seamless Internet access service that works regardless of which IP version, any two endpoints are using. > Maybe I'm reading too much into your statement, but you're > implicitly saying that IPv4 addresses will have NO value in two years. They have no intrinsic value today. Things will get tight for a while, but once it is clear that IPv6 is relatively easy to deploy with reasonable capex/opex, I don't see how IPv4 addresses can retain any value that they *MIGHT* have gathered in the next couple of years. Some people are really pushing for IP addresses to be monetized, and it may happen to some extent, but if it does, it will collapse in about two years when the IPv6 technical issues are mostly solved. In other words, if you want return on your investments, then get working on seamless IPv6-IPv4 interworking. > I'm quite sure that using *my* current IPv4 addresses, I Current? What about "two years from now" makes you think of today? >I'm sorry if it sounds > cynical, but I just don't see vendors, ISPs, or businesses > demanding that they or anybody else ready for IPv6 *now* for > what might happen in two years. Rip van Winkle, eh? Have a look at Cisco's and Juniper's website and you will see that they have been doing IPv6 ready for years. Look on ARIN's wiki to find the April 2nd article in Network World that tells what several of the largest US ISPs are doing. http://www.getipv6.info/index.php/IPv6_in_the_News Same website has this page http://www.getipv6.info/index.php/IPv6_at_ARIN_XXI with links to various work being done right now to iron out the interworking issues between IPv4 and IPv6. Before you know it some market analyst will start asking telecoms CEO's what they are doing to prepare for the IPv4 runout in 2010 and share values will dive (or not) based on the answers. > You'll probably just see proxies/caches/NATs being used to > expand IPv4 address space, and anyone launching a new web > service is going to need to find someone to host it on an > IPv4 server, or their business is going to go bust, because > they will be talking to a small crowd of IPv6 users, or only > aiming at users in emerging markets/developing countries. Hosting providers can run 6to4 gateways so that v6 websites are fully accessible. If you are going to invest in proxies caches and NAT, then NAT-PT seems like the most risk-free way to do that. --Michael Dillon From michael.dillon at bt.com Sat May 3 18:30:25 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 3 May 2008 23:30:25 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <481B7E09.9000406@psg.com> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <481B3629.4000308@chl.com> <481B7BC6.7040207@bogomips.com> <481B7E09.9000406@psg.com> Message-ID: > have you not read? peano's postulates are being revoked 1 april 2010. > end of internet numbers predicted. news at 11. Seems to me that most NAT installations have violated Peano's postulates for many years now. NAT-PT just continues the tradition. --Michael Dillon From michael.dillon at bt.com Sat May 3 18:51:44 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 3 May 2008 23:51:44 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <011401c8ac9a$e6d6d880$6fce4b41@tedsdesk> References: <011401c8ac9a$e6d6d880$6fce4b41@tedsdesk> Message-ID: > Here in the US we do not have active hot wars going on over > the Louisiana Purchase, but they most definitely have them > going on in the Mid East with regards to Israel's land ownership. But in Canada there has been a low-level hot war going on for over 20 years, specifically with regard to who owns the land occupied by aboriginal peoples when Europeans first claimed land in North America. Not too many people have been killed, but there have been several armed confrontations. > Eventually one day the allocation of IP addresses is going to > be formalized in a law somewhere in some government - and > they will base that law on the precident that's being created > right now by people doing what they are doing today - and > that's being created partly by "opinions we may state on this list" No, none of it is being created by opinions on this list. However, some of it may very well be based on opinions handed down by Canada's Supreme Courts regarding aboriginal land claims. Vast areas of land have been recognized as being owned by aboriginal peoples, and where that land is now occupied by cities, the courts have ordered compensation to be paid. It is a hugely complex area of law, and since it is a form of international law (the law between sovereign nations) it could very well form a precedent for how international law develops in regard to "Internet properties". > It already is. The entire IPv6 allocation system is based on how > we do things with IPv4. People are proposing some breaks with the past in regards to IPv4. I'm not so sure that they have thought out all the implications that this has for IPv6. > Also, that soldier is breaking the laws of the government of > the people > he is killing, and if he is caught and put into a POW camp by > that government, they can torture him without breaking their > laws. Not if they signed the Geneva convention on war. This is an international treaty which, in effect, creates international laws. These laws have been used to prosecute people after WW II in Nurnberg and more recently in the International Court of Justice in the Hague. When a country signs an international treaty and then ratifies it in their parliament/congress, this treaty becomes part of their law. This is the basic principle underlying the European Union where the group of countries signed more and more treaties which then intruded more and more into their local laws. The NAFTA treaties are similar, although they are not as extensive as the EU agreements. --Michael Dillon From michael.dillon at bt.com Sat May 3 19:00:52 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 4 May 2008 00:00:52 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan><29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan><29A54911243620478FF59F00EBB12F4701083E80@ex01.drtel.lan> Message-ID: > The IANA has primarily allocated > address space to the Internet Registry (DDN NIC and InterNIC) > and its successor, the RIRs. Actually, I believe that the IANA primarily defines new SNMP MIBs. It also assigns TCP and UDP port numbers and various other kinds of Internet identifiers. As you pointed out, it has rarely ever allocated IP addresses directly preferring to delegate that work to the InterNIC and the RIRs. I just wanted to emphasize that the IANA has a much broader role than just being the top-level of the IP address allocation hierarchy. Mind you, it was over 10 years ago when I was told about the volume of work being mostly MIB definitions. It may have changed since then. --Michael Dillon From gih at apnic.net Sat May 3 23:02:17 2008 From: gih at apnic.net (Geoff Huston) Date: Sun, 04 May 2008 13:02:17 +1000 Subject: [arin-ppml] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <70031.1209831769@sa.vix.com> References: <70031.1209831769@sa.vix.com> Message-ID: <481D2739.1060605@apnic.net> I keep on saying: its just a mathematical model, and the way this will play out is invariably different from our best guesses. So to say "well there's x days to go" is somewhat misleading as it appears to vest this model with some air of authority about the future, and that's not a good idea! The salient observation, made here and in other places, is that address allocation is a rather skewed distribution. Most address allocations are relatively small, but a small number of them are relatively large. Its the the timing of this smaller set of actors who are undertaking large deployments that will ultimately determine how this plays out. It could be a lot faster than 1000 days, or it could be slower - its very uncertain, There could be some "last minute rush." There could be a change in policies over remaining address pools as the pool diminishes, or .... So, yes, the pool is visibly draining and you now can see all the way to the bottom! And it looks like there are around 3 years to go ... but thats with an uncertainty factor of at least +/- about 1 1/2 years! Geoff Paul Vixie wrote: > from nanog, which means most ppml'ers have seen it, but some not. there was > the usual set of responses from the usual people, mostly sarcastic. re: > > > > ------------------------------------------------------------------------ > > Subject: > [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion > From: > mleber at he.net (Mike Leber) > Date: > Fri, 2 May 2008 11:51:43 -0700 (PDT) > > Newsgroups: > local.mail.net.nanog > > > Since nobody mentioned it yet, there are now less than 1000 days projected > until IPv4 exhaustion: > > http://www.potaroo.net/tools/ipv4/ > From BillD at cait.wustl.edu Sun May 4 17:29:55 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Sun, 4 May 2008 16:29:55 -0500 Subject: [arin-ppml] fair warning: less than 1000 days left toIPv4 exhaustion References: <70031.1209831769@sa.vix.com> <481D2739.1060605@apnic.net> Message-ID: Please no one disabuse the messenger.... Geoff disclaims certainty in the 1000 days scenario...and of course most clear see the numbers and estimates for what they are. But, given that we can see the bottom of the pool and + or - 1 1/2 years, it's 3....then that should offer very little consolation to those who think 3 is concrete. The range 1.5-4.5 is perhaps scarier.... bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Geoff Huston Sent: Sat 5/3/2008 10:02 PM To: Paul Vixie Cc: ppml at arin.net Subject: Re: [arin-ppml] fair warning: less than 1000 days left toIPv4 exhaustion I keep on saying: its just a mathematical model, and the way this will play out is invariably different from our best guesses. So to say "well there's x days to go" is somewhat misleading as it appears to vest this model with some air of authority about the future, and that's not a good idea! The salient observation, made here and in other places, is that address allocation is a rather skewed distribution. Most address allocations are relatively small, but a small number of them are relatively large. Its the the timing of this smaller set of actors who are undertaking large deployments that will ultimately determine how this plays out. It could be a lot faster than 1000 days, or it could be slower - its very uncertain, There could be some "last minute rush." There could be a change in policies over remaining address pools as the pool diminishes, or .... So, yes, the pool is visibly draining and you now can see all the way to the bottom! And it looks like there are around 3 years to go ... but thats with an uncertainty factor of at least +/- about 1 1/2 years! Geoff Paul Vixie wrote: > from nanog, which means most ppml'ers have seen it, but some not. there was > the usual set of responses from the usual people, mostly sarcastic. re: > > > > ------------------------------------------------------------------------ > > Subject: > [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion > From: > mleber at he.net (Mike Leber) > Date: > Fri, 2 May 2008 11:51:43 -0700 (PDT) > > Newsgroups: > local.mail.net.nanog > > > Since nobody mentioned it yet, there are now less than 1000 days projected > until IPv4 exhaustion: > > http://www.potaroo.net/tools/ipv4/ > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppml at rs.seastrom.com Sun May 4 23:05:14 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sun, 04 May 2008 23:05:14 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: (michael dillon's message of "Sun, 4 May 2008 00:00:52 +0100") References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E80@ex01.drtel.lan> Message-ID: <86skwx4fit.fsf@seastrom.com> writes: >> The IANA has primarily allocated >> address space to the Internet Registry (DDN NIC and InterNIC) >> and its successor, the RIRs. > > Actually, I believe that the IANA primarily defines new SNMP MIBs. It > also assigns TCP and UDP port numbers and various other kinds of > Internet identifiers. As you pointed out, it has rarely ever allocated > IP addresses directly preferring to delegate that work to the InterNIC > and the RIRs. > > I just wanted to emphasize that the IANA has a much broader role than > just being the top-level of the IP address allocation hierarchy. Mind > you, it was over 10 years ago when I was told about the volume of work > being mostly MIB definitions. It may have changed since then. Taken in context it appears that Ray's intent was to enumerate the recipients of space from IANA and state that they were for the most part the IR and RIRs, not to insinuate that this was IANA's primary job function. Given that MIBs and port/protocol numbers have only the most tenuous relationship to address allocation policy, I'm not sure what the point was in bringing it up - someone is doubtless charged with keeping the soda machine stocked at IANA too, but that task isn't germane to this list either. ---rob From michael.dillon at bt.com Mon May 5 03:59:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 May 2008 08:59:10 +0100 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: References: <70031.1209831769@sa.vix.com> <481D2739.1060605@apnic.net> Message-ID: > Geoff disclaims certainty in the 1000 days scenario...and of course most clear see the numbers and estimates for what they are. > But, given that we can see the bottom of the pool and + or - 1 1/2 years, it's 3....then that should offer very little consolation to those who think 3 is concrete. > The range 1.5-4.5 is perhaps scarier.... Last year, less than 300 days ago, this counter showed 1300 days and it was publicised a lot. I checked it several months later and the number had gone up to more than 1400, I believe. Now suddenly it is down to 1000!!! It almost seems like we consume addresses slower than average for a while, then a large allocation goes out and we have suddenly consumed more than the average amount. Since we have no way of knowing when larger allocations will happen perhaps the 1.5 year figure is more likely than the 3 year figure. In any case, the exact runout date is irrelevant. What is more important is knowing the nearest possible date for runout since that is the date you want to target with your IPv6 readiness plans. If you are IPv6 ready in 1.5 years, then it doesn't matter when IPv4 addresses run out. If you need 3 years to become IPv6 ready, then you have a problem. --Michael Dillon -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Mon May 5 04:03:35 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 May 2008 09:03:35 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <86skwx4fit.fsf@seastrom.com> References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan><29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan><29A54911243620478FF59F00EBB12F4701083E80@ex01.drtel.lan> <86skwx4fit.fsf@seastrom.com> Message-ID: > Given that MIBs > and port/protocol numbers have only the most tenuous > relationship to address allocation policy, I'm not sure what > the point was in bringing it up I don't see what the point is in encouraging ignorance and narrow-mindedness. Of course one can interpret the whole world in terms of IP allocation activities if one wishes, but what is the point? IANA does not exist solely to manage the top of the IP addressing hierarchy. In fact that is likely that IP addressing is not its primary role, just another one of those legacy things, which is why an organization like the NRO exists. Not everyone on this list is an Internet policy junkie so why do you have a problem with a little bit of educational material being posted? --Michael Dillon From paul at vix.com Mon May 5 04:10:21 2008 From: paul at vix.com (Paul Vixie) Date: Mon, 05 May 2008 08:10:21 +0000 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: Your message of "Mon, 05 May 2008 08:59:10 +0100." References: <70031.1209831769@sa.vix.com> <481D2739.1060605@apnic.net> Message-ID: <20583.1209975021@sa.vix.com> > In any case, the exact runout date is irrelevant. What is more important > is knowing the nearest possible date for runout since that is the date > you want to target with your IPv6 readiness plans. If you are IPv6 ready > in 1.5 years, then it doesn't matter when IPv4 addresses run out. If you > need 3 years to become IPv6 ready, then you have a problem. > > --Michael Dillon if on the other hand ipv6 isn't going to make or save any money this year for those who deploy it, because not enough others have deployed it, and if the undepreciated capital plant doesn't support it so it would take capital spending to get it done, then deploying ipv6 is a bad idea. no earlypoints. lather, rinse, repeat. i don't like it, but there it is. From BillD at cait.wustl.edu Mon May 5 09:41:02 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 5 May 2008 08:41:02 -0500 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4exhaustion In-Reply-To: <20583.1209975021@sa.vix.com> References: <70031.1209831769@sa.vix.com> <481D2739.1060605@apnic.net> <20583.1209975021@sa.vix.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Monday, May 05, 2008 3:10 AM > To: michael.dillon at bt.com > Cc: ppml at arin.net > Subject: Re: [arin-ppml] fair warning: less than 1000 days > lefttoIPv4exhaustion > > > In any case, the exact runout date is irrelevant. What is more > > important is knowing the nearest possible date for runout > since that > > is the date you want to target with your IPv6 readiness > plans. If you > > are IPv6 ready in 1.5 years, then it doesn't matter when IPv4 > > addresses run out. If you need 3 years to become IPv6 > ready, then you have a problem. > > > > --Michael Dillon > > if on the other hand ipv6 isn't going to make or save any > money this year for those who deploy it, because not enough > others have deployed it, and if the undepreciated capital > plant doesn't support it so it would take capital spending to > get it done, then deploying ipv6 is a bad idea. no earlypoints. > > lather, rinse, repeat. > > i don't like it, but there it is. This certainly reminds me of the earlier days of corporate ramp-up with information security. All tangible expenditure and NO tangible benefits. The way forward seemed to be selling it as a benefit to future relationships and demonstrating/emphasizing the capability and trust-worthiness of the 'enhanced' enterprise. It was still intangible, but it changed the focus from 'protecting oneself' to 'selling the business'. ...can't quite see, though...still groping for a towel.... > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From ppml at rs.seastrom.com Mon May 5 11:06:40 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 05 May 2008 11:06:40 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: (michael dillon's message of "Mon, 5 May 2008 09:03:35 +0100") References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E62@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701083E80@ex01.drtel.lan> <86skwx4fit.fsf@seastrom.com> Message-ID: <86skww7ptr.fsf@seastrom.com> writes: >> Given that MIBs >> and port/protocol numbers have only the most tenuous >> relationship to address allocation policy, I'm not sure what >> the point was in bringing it up > > I don't see what the point is in encouraging ignorance and > narrow-mindedness. Of course one can interpret the whole world > in terms of IP allocation activities if one wishes, but what is > the point? IANA does not exist solely to manage the top of the > IP addressing hierarchy. In fact that is likely that IP addressing > is not its primary role, just another one of those legacy things, > which is why an organization like the NRO exists. > > Not everyone on this list is an Internet policy junkie so why do > you have a problem with a little bit of educational material > being posted? Would you say the same thing if people objected to Earth Day stuff or an article on how to repair model cars were posted to PPML? If not, then you have answered your own question. ---rob From dean at av8.net Mon May 5 13:06:38 2008 From: dean at av8.net (Dean Anderson) Date: Mon, 5 May 2008 13:06:38 -0400 (EDT) Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: <71981.1209836949@sa.vix.com> Message-ID: I note that of the supposed 1% that you do respond to, that you never actually refute any of the accusations in those responses, either. I've been keeping track. --Dean On Sat, 3 May 2008, Paul Vixie wrote: > for the record, then: > > > ... > > Guilmette associates with Alan Brown, Mathew Sullivan, and John Levine > > through the spam-l list. Brown is formerly the operator of ORBS.ORG, > > shut for defamation after making false claims about open relays to > > profit Brown's ISP, which was also lost in payment of damages). Matthew > > Sullivan is the ostensible operator SORBS.ORG with Paul Vixie and Dave > > Rand. SORBS.ORG was hosted by unelected ARIN Board Member Paul Vixie. > > Vixie denied hosting SORBS and transferred the service to his MAPS.ORG > > co-founder Dave Rand, but forgot to remove the in-addr.arpa entries. > > While denying involvement with SORBS, Vixie has curiously been willing > > to discuss the SORBS business model on ARIN-DISCUSS. ARIN-DISCUSS is > > the mailing list restricted to ARIN members for ARIN business, and it > > seems to be at least a conflict of interest for Board Members to promote > > their own business using ARIN resources. Levine is a business partner > > of Paul Vixie in a commercial bulk email operation called Whitehat. > > ... > > for the record, it isn't december of an odd numbered year, and so, i won't > be disputing, refuting, explaining, arguing, or discussing in detail any of > dean anderson's statements about me or my activities. a man's got to know > his limitations. one weekend out of 100, i will worry about what onlookers > might think of dean's repeated accusations of malfeasance against me. this > isn't the one. i know i used to give more than 1%, but it was way too much. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From tedm at ipinc.net Mon May 5 13:40:11 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 May 2008 10:40:11 -0700 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: Message-ID: <014d01c8aed7$11b93050$6fce4b41@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte > Sent: Sunday, May 04, 2008 2:30 PM > To: Geoff Huston; Paul Vixie > Cc: ppml at arin.net > Subject: Re: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion > Please no one disabuse the messenger.... > Geoff disclaims certainty in the 1000 days scenario...and of course most clear see the numbers and > estimates for what they are. > But, given that we can see the bottom of the pool and + or - 1 1/2 years, it's 3....then that > should offer very little consolation to those who think 3 is concrete. > The range 1.5-4.5 is perhaps scarier.... To whom? You know the interesting thing about this is that the ONLY people who are scared about IPv4 runout are those who have a GROWING need for IP addresses. Not all ISPs out there have this. Some ISP's are not growing, they are shrinking. Others are neither growing nor shrinking but are steady state. Some have a lot of wasted IPv4 internally due to allocation schemes that no longer matched the current reality. Reminds me of a customer we had at one time on a 56k line from a time period of something like 1994 to 2005 - after the initial 2 year contract was up with them, they went month-to-month and from that point on refused to resign a contract - we were charging them around $300 a month for a 56k point to point circuit and we did so for 11 years - their hangup? We had assigned them a /24 of IPv4 (199.248.255.x) and they did not want to renumber out of it, and they even had a firewall and none of these numbers were accessible from the outside. Do you think we would have ever sent them a letter saying we were forcing them to renumber? Hell no! I'll take $300 for a 56k dedicated line any day. And to top it off the subnet itself is currently in limbo-land, unused, unadvertised, and will likely never be corrected since the admin contact on it is on a domain for an out-of-business company that's currently held by a speculator. I'm quite sure there's a lot of ISP's out there that over the years have had stuff like this going on - they are satisfying their internal growth needs by more efficient utilizations. IPv4 runout isn't going to immediately affect these organizations. >From my seat by the fire the orgs that are going to be screwed are the ones that have very rapidly growing networks that consume enormous numbers of IP addresses. And those orgs are the ones that have the bulk of the IPv4 tied up, in my opinion. When IPv4 runout happens, they will be forced to go to IPv6 since there will be no other answer for them - they won't be able to "buy" on the open market sufficient IPv4 to meet their needs, even if there was an "IPv4 market". And once they switch over to IPv6, why then the IPv4 that they discard will go back to the RIRs - and be available for hand-out again. It won't be in blocks large enough to satisfy these kinds of orgs, but it will be in blocks large enough to satisfy the needs of the smaller orgs. Ted From tedm at ipinc.net Mon May 5 14:03:01 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 May 2008 11:03:01 -0700 Subject: [arin-ppml] Legacy Space authority In-Reply-To: Message-ID: <014e01c8aeda$4223dfd0$6fce4b41@tedsdesk> > -----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: Saturday, May 03, 2008 3:52 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority > > > > Here in the US we do not have active hot wars going on over > > the Louisiana Purchase, but they most definitely have them > > going on in the Mid East with regards to Israel's land ownership. > > But in Canada there has been a low-level hot war going on for > over 20 years, specifically with regard to who owns the land > occupied by aboriginal peoples when Europeans first claimed > land in North America. Not too many people have been killed, > but there have been several armed confrontations. > > > Eventually one day the allocation of IP addresses is going to > > be formalized in a law somewhere in some government - and > > they will base that law on the precident that's being created > > right now by people doing what they are doing today - and > > that's being created partly by "opinions we may state on this list" > > No, none of it is being created by opinions on this list. > However, some of it may very well be based on opinions handed > down by Canada's > Supreme Courts regarding aboriginal land claims. Vast areas > of land have been recognized as being owned by aboriginal > peoples, and where that land is now occupied by cities, the > courts have ordered compensation to be paid. It is a hugely > complex area of law, and since it is a form of international > law (the law between sovereign nations) it could very well > form a precedent for how international law > develops in regard to "Internet properties". This is a ripe example of circular logic as I have ever seen. Your arguing that IP addressing is property, and property is subject to future legal decisions of a court which will end up proving that IP addressing is property. Kind of like the people that claim the Bible is the actual word of God and the reason being is that it says so in the Bible. > > It already is. The entire IPv6 allocation system is based > on how we > > do things with IPv4. > > People are proposing some breaks with the past in regards to > IPv4. I'm not so sure that they have thought out all the > implications that this has for IPv6. > Well, since the IPv6 RSA that you have to sign to get IPv6 states that by signing you agree that IP numbers aren't property, I think that every day, week, month & year that passes results in more and more IPv6 assigned under that agreement, and less and less chance that 20 years in the future some court will overturn that part of the agreement. There may be some bad things with regards to IPv6 assignment but at least this Legacy IPv6 argument won't be a burden to our children trying to run things on the Internet. > > Also, that soldier is breaking the laws of the government of > > the people > > he is killing, and if he is caught and put into a POW camp by > > that government, they can torture him without breaking their > > laws. > > Not if they signed the Geneva convention on war. This is an > international treaty which, in effect, creates international > laws. These laws have been used to prosecute people after WW > II in Nurnberg and more recently in the International Court > of Justice in the Hague. When a country signs an > international treaty and then ratifies it in their > parliament/congress, this treaty becomes part of their law. > This is the basic principle underlying the European Union > where the group of countries signed more and more treaties > which then intruded more and more into their local laws. The > NAFTA treaties > are similar, although they are not as extensive as the EU agreements. > Except for the loophole which the US showed the rest of the world which is to merely claim that the soldier was a non-combatant and that Geneva does not apply, and is a non-citizen so has no legal rights to appeal for relief under your laws, and to further claim that the torture wasn't really torture. Thus, once more it turns in to what your point of view is. Even if the rest of the world all agrees that the soldier was a legal combatant, and what you were doing to him was indeed torture, what your doing to him is still legal within your system of laws. If the rest of the world decides to "not invade you" such as is being done with North Korea and Iran, why then as long as you don't step out of the borders of your own country, you will never be subject to the rest of the world's laws and you can live to a ripe old age and die contented that you have never broken the law. The ICJ in The Hague is extremely unlikely to take up an IP addressing case until WIPO has weighed in on it. And I find that very unlikely, if they were going to do that, they would have done it when they extended copyright over Internet domain names. Ted From tedm at ipinc.net Mon May 5 14:09:14 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 May 2008 11:09:14 -0700 Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: Message-ID: <014f01c8aedb$210e1120$6fce4b41@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dean Anderson > Sent: Monday, May 05, 2008 10:07 AM > To: Paul Vixie > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority (fwd) > > > I note that of the supposed 1% that you do respond to, that > you never actually refute any of the accusations in those > responses, either. I note in the 100% of these that YOU respond to by claiming your going to set your lawyer on suing any of these organizations and people, YOU never actually do so, either. > I've been keeping track. Must...restrain...myself...from...making...smartass...comment.... very....difficult..... Ted From kkargel at polartel.com Mon May 5 14:27:01 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 5 May 2008 13:27:01 -0500 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <014e01c8aeda$4223dfd0$6fce4b41@tedsdesk> References: <014e01c8aeda$4223dfd0$6fce4b41@tedsdesk> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A106BA@mail> >> The ICJ in The Hague is extremely unlikely to take up an IP addressing case until WIPO has weighed in on it. And I find that very unlikely, if they were going to do that, they would have done it when they extended copyright over Internet domain names. Ah, but WIPO has no problem ruling on DNS issues.. Such as http://www.wipo.int/amc/en/domains/decisions/html/2002/d2002-0029.html and http://www.wipo.int/amc/en/domains/decisions/html/2000/d2000-1581.html or even http://www.wipo.int/amc/en/domains/decisions/html/2001/dtv2001-0010.html WIPO refers to "Internet Address" synonomously with "Domain Name" and defines it as a "human friendly form" of the numeric Internet Protocol address. WIPO came dangerously close to making a statement about IP numerical addressing as property in http://www.wipo.int/amc/en/processes/process1/rfc/3/interim2_ch1.html I do not think it is a far stretch to imagine that WIPO will make a finding should a well defined case be presented to them concerning internet numbers. From Dan.Thorson at seagate.com Mon May 5 14:36:35 2008 From: Dan.Thorson at seagate.com (Dan.Thorson at seagate.com) Date: Mon, 5 May 2008 13:36:35 -0500 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: <014d01c8aed7$11b93050$6fce4b41@tedsdesk> Message-ID: I apologize in advance, and perhaps I'm missing the entire point... but I think it's all a bit absurd that many of the participants of this email list think that we should all be migrating to IPv6 today, and that if we're not already in-process then woe-be-to-me. For an enterprise customer's perspective things look a bit different. Here's a response I received from one of the most well known telecommunication providers in the USA (when asked about providing IPv6 BGP peering across our Internet circuit) "Commercial products are expected to become available starting in 2009. For MIS in particular, Current plans are for IPv6 to be made available on a limited basis on MIS in 1Q09 with general availability scheduled for 4Q09." So: a huge ISP/telecom provider in the US is saying they'll provide IPv6 to me in about 18 months. A query to one of my other upstreams provided this: "We are currently evaluating our IPv6 solution in our lab, but it is not something that we offer today. We will be making a decision of general availability at the beginning of Q3 2008." So this smaller ISP (with reach in to a reasonable fraction of the US) will THINK about availability in a few months. That's not any kind of guarantee that they actually WILL provide it. So I please beg everybody's pardon when I say, speaking ONLY for me (and not my company), that I do not have any sense of urgency re: an IPv6 conversion/rollout, since clearly my upstreams don't have any. I suspect the biggest problem will be for the company which opens their doors in 3 years, and tries to get IP space, and finds that they can only get IPv6... and then discovers that only a fraction of the people on the Internet can reach their www site. THEN it's gonna hit the fan. In ignorance, I provide my $0.02 worth. danT =================================================== Dan Thorson - CCIE 10754 =================================================== From jcurran at istaff.org Mon May 5 14:49:42 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 5 May 2008 14:49:42 -0400 Subject: [arin-ppml] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: Message-ID: At 1:36 PM -0500 5/5/08, Dan.Thorson at seagate.com wrote: >So I please beg everybody's pardon when I say, speaking ONLY for me (and >not my company), that I do not have any sense of urgency re: an IPv6 >conversion/rollout, since clearly my upstreams don't have any. Dan - There are major ISP's who will provide IPv6 today, and alternatively you can readily obtain a IPv6 to let you begin with your own planning and testing. >I suspect the biggest problem will be for the company which opens their >doors in 3 years, and tries to get IP space, and finds that they can only >get IPv6... and then discovers that only a fraction of the people on the >Internet can reach their www site. THEN it's gonna hit the fan. Correct. You can reduce the fallout a little bit by having *your* key public servers (i.e. public web, SMTP, and DNS) IPv6-connected and reachable. This doesn't eliminate the problem, but at least allows that new company have some level of interaction with your company. /John From tedm at ipinc.net Mon May 5 14:50:36 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 May 2008 11:50:36 -0700 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A106BA@mail> Message-ID: <015c01c8aee0$e8543840$6fce4b41@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Monday, May 05, 2008 11:27 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority > > > > >> >> The ICJ in The Hague is extremely unlikely to take up an IP >> addressing case until WIPO has weighed in on it. And I find >> that very unlikely, if they were going to do that, they would >> have done it when they extended copyright over Internet domain names. >> >> Ah, but WIPO has no problem ruling on DNS issues.. Such as >> http://www.wipo.int/amc/en/domains/decisions/html/2002/d2002-0029.html >> and >> http://www.wipo.int/amc/en/domains/decisions/html/2000/d2000-1581.html >> or even >> http://www.wipo.int/amc/en/domains/decisions/html/2001/dtv2001 >>-0010.html > WIPO refers to "Internet Address" synonomously with "Domain Name" and defines > it as a "human >friendly form" of the numeric Internet Protocol address. > WIPO came dangerously close to making a statement about IP numerical addressing as property in > http://www.wipo.int/amc/en/processes/process1/rfc/3/interim2_ch1.html > I do not think it is a far stretch to imagine that WIPO will make a finding should > a well defined case be presented to them concerning internet numbers. Oh, I'm sure if someone pushed them against a wall they would make a finding - that IP addresses are NOT property. Despite what The Disney Company would like, not everything is copyrightable for an indefinite period of time. Imagine if WIPO found IP addresses were property and subject to copyright. Based on that precident you would have a perfect argument for saying that telephone numbers are also property. So now when a business moves cross country their phone number including the area code is required to go with them. Or even better than phone numbers, street addresses. One Microsoft Way for example, - if they moved, the receiving city would be legally required to change the street name - and what happens to all the other businesses on the same street who -also- have copyrighted street addresses. Oh, sure, have WIPO go out there and rule that IP addresses are property. Then watch WIPO become totally irrelevant as the legal implications of the decision sink in - and the world's governments start ignoring them. Ted From jcurran at istaff.org Mon May 5 14:52:14 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 5 May 2008 14:52:14 -0400 Subject: [arin-ppml] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: Message-ID: At 2:49 PM -0400 5/5/08, John Curran wrote: > > There are major ISP's who will provide IPv6 today, and alternatively > you can readily obtain a IPv6 to let you begin with your own planning Apologies; should be "readily obtain an IPv6 tunnel" (if not obvious :-) /John From BillD at cait.wustl.edu Mon May 5 14:59:00 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 5 May 2008 13:59:00 -0500 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: <014d01c8aed7$11b93050$6fce4b41@tedsdesk> References: <014d01c8aed7$11b93050$6fce4b41@tedsdesk> Message-ID: > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Monday, May 05, 2008 12:40 PM > To: Bill Darte; 'Geoff Huston'; 'Paul Vixie' > Cc: ppml at arin.net > Subject: RE: [arin-ppml] fair warning: less than 1000 days > lefttoIPv4 exhaustion > > > > The range 1.5-4.5 is perhaps scarier.... > > To whom? > > You know the interesting thing about this is that the ONLY > people who are scared about IPv4 runout are those who have a > GROWING need for IP addresses. The law of unintended consequences affects not only primarly players in change. Preparations for business as usual is always a strategic problem. Not engaging the issue of IPv4 runout and IPv6 adoption, changed transfer policy and perterbations in the governance roles of the Internet are issues that 'may' make an impact on organizations and individuals not matter how hard they try to ignore them...I'm thinking. > > Not all ISPs out there have this. Some ISP's are not > growing, they are shrinking. > Others are neither growing nor shrinking but are steady > state. Some have a lot of wasted IPv4 internally due to > allocation schemes that no longer matched the current > reality. Reminds me of a customer we had at one time on a > 56k line from a time period of something like 1994 to 2005 - > after the initial 2 year contract was up with them, they went > month-to-month and from that point on refused to resign a > contract - we were charging them around $300 a month for a > 56k point to point circuit and we did so for 11 years - their > hangup? We had assigned them a /24 of IPv4 (199.248.255.x) > and they did not want to renumber out of it, and they even > had a firewall and none of these numbers were accessible from > the outside. Do you think we would have ever sent them a > letter saying we were forcing them to renumber? Hell no! > I'll take $300 for a 56k dedicated line any day. > And to top it off the subnet itself is currently in > limbo-land, unused, unadvertised, and will likely never be > corrected since the admin contact on it is on a domain for an > out-of-business company that's currently held by a speculator. > > I'm quite sure there's a lot of ISP's out there that over the > years have had stuff like this going on - they are satisfying > their internal growth needs by more efficient utilizations. > IPv4 runout isn't going to immediately affect these organizations. > > From my seat by the fire the orgs that are going to be > screwed are the ones that have very rapidly growing networks > that consume enormous numbers of IP addresses. And those > orgs are the ones that have the bulk of the IPv4 tied up, in > my opinion. When IPv4 runout happens, they will be forced to go to > IPv6 > since there will be no other answer for them - they won't be > able to "buy" > on the open market sufficient IPv4 to meet their needs, even > if there was an "IPv4 market". And once they switch over to > IPv6, why then the IPv4 that they discard will go back to the > RIRs - and be available for hand-out again. > It won't be in blocks large enough to satisfy these kinds of > orgs, but it will be in blocks large enough to satisfy the > needs of the smaller orgs. > > Ted > > From jmorrison at bogomips.com Mon May 5 15:00:26 2008 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 05 May 2008 12:00:26 -0700 Subject: [arin-ppml] Legacy Space authority In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701083E50@ex01.drtel.lan> <481B3629.4000308@chl.com> <481B7BC6.7040207@bogomips.com> Message-ID: <481F594A.2020706@bogomips.com> michael.dillon at bt.com wrote: >> Maybe I'm reading too much into your statement, but you're >> implicitly saying that IPv4 addresses will have NO value in two years. >> > > They have no intrinsic value today. Things will get tight for a while, > but once it is clear that IPv6 is relatively easy to deploy with > reasonable > capex/opex, I don't see how IPv4 addresses can retain any value that > they *MIGHT* have gathered in the next couple of years. Some people > are really pushing for IP addresses to be monetized, and it may > happen to some extent, but if it does, it will collapse in about two > years when the IPv6 technical issues are mostly solved. > Let's not get into existential hair-splitting about value. Common sense says that IPv4 addresses have do have value in a number of ways. They can be used for commercial purposes, and possessing the right to use/hold them gives the bearer ("owner" although many don't like the word) some use and value, and possible resale value. You might as well say that a $100 bill (or Euro) has no intrinsic value - well "obviously" they're just pieces of paper with no "intrinsic" value, but I can still do a lot more with a $100 bill than a blank sheet of paper. Your original point was that a person would be foolish to put any value on IPv4 addresses in two years. Now you're saying they might at least be valuable as a hedge... It isn't obvious yet that Telcos won't find a way to profit from the IPv4 exhaustion simply by extortion. Pay us more, or we can't guarantee IPv4 connectivity, or pay us more for IPv6 connectivity, but be able to talk to almost no-one at first. What would most people opt for? Anyone who gets their IP address today by DHCP will probably see their routable IPv4 addresses re-claimed or have to pay more for them. Will the broadband companies hold the hands of millions of users to upgrade to IPv6, or just proxy/nat? Will hosting providers pay to upgrade and jump through paperwork hoops when those same broadband companies still keep bringing them to their door? >> I'm sorry if it sounds >> cynical, but I just don't see vendors, ISPs, or businesses >> demanding that they or anybody else ready for IPv6 *now* for >> what might happen in two years. >> > > Rip van Winkle, eh? Have a look at Cisco's and Juniper's website > and you will see that they have been doing IPv6 ready for years. > Look on ARIN's wiki to find the April 2nd article in Network > World that tells what several of the largest US ISPs are > doing. http://www.getipv6.info/index.php/IPv6_in_the_News > > Hardly. I've been following IPv6 since TUBA, and remember listening to Steeve Deering in the mid 90's presenting the just finished IPv6, and saying it would take a few years. I don't recall the time frame, but I recall him mentioning that some network had just finished ripping out XNS (or whatever) after twenty years, and that IPv4 would be with us for a time. I've read the IPv6 docs, as well as implemented it for testing, and am very aware of what the vendors are doing. There's also lots of docs on how to setup CLNS and IS-IS, which was mandated by Government procurement regulations. I believe the US GSA has mandated IPv6 as well, so no surprise that there's IPv6 support. Vendors are simply marketing the features, you won't find vendor sales or consulting engineers pushing IPv6 up front or telling Enterprises that the wolf is at the door. IPv6 is a footnote, nice to have. I'm not knocking IPv6 - "I want to believe"! But I just don't see IPv4 collapsing, I just see the ISPs cannibalizing their networks and kludging things up to keep business working as usual. IPv6 could probably have been (and maybe should be) just a seamless, one line feature on your boxes, and at one point renumbering and other transition mechanisms were proposed but never materialized. There's short term tunnels, fixes and workarounds but not really an "easy button" yet, at least for the end user. I would be more hopeful predicting that vendors, OS makers and customers (aka the market) will form a loose consensus on a seamless way to turn on IPv6, than I would be in predicting the IPv4 Internet is going to end in two years, which seems the only way IPv4 addresses will cease to have value. > Same website has this page > http://www.getipv6.info/index.php/IPv6_at_ARIN_XXI > with links to various work being done right now to iron out the > interworking > issues between IPv4 and IPv6. > > Before you know it some market analyst will start asking telecoms CEO's > what they are doing to prepare for the IPv4 runout in 2010 and share > values will dive (or not) based on the answers. > > Important but probably academic. Business will not cease for those telecoms because IPv4 is not going to drop dead, they can shift address space around - and make extra money on top of it all, and because most can reasonably say to auditors that they could implement IPv6 if they had too. >> You'll probably just see proxies/caches/NATs being used to >> expand IPv4 address space, and anyone launching a new web >> service is going to need to find someone to host it on an >> IPv4 server, or their business is going to go bust, because >> they will be talking to a small crowd of IPv6 users, or only >> aiming at users in emerging markets/developing countries. >> > Hosting providers can run 6to4 gateways so that v6 websites > are fully accessible. If you are going to invest in proxies > caches and NAT, then NAT-PT seems like the most risk-free way > to do that. Of course - but will hosting providers be the ones spending a lot of money for appliances and licenses, not to mention upgrades/changes to routers and Internet feeds, to handle a trickle of new IPv6 users, or will it be business as usual for some time? Or will it be the DSL and Cable ISPs with huge existing IPv4 allocations, who already have proxies? Won't they be the ones with an economic incentive to conserve IPv4 addresses and re-market or "sell" them? Will a routable IPv4 address suddenly become a "business package" service for DSL/Cable users, at a premium price? Whatever happened to all those IPv6 addresses on millions of cell phones that was supposed to drive IPv6? Seems like proxying works fine and profitably for the mobile telcos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Mon May 5 15:01:39 2008 From: dogwallah at gmail.com (McTim) Date: Mon, 5 May 2008 22:01:39 +0300 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A106BA@mail> References: <014e01c8aeda$4223dfd0$6fce4b41@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A063141066A106BA@mail> Message-ID: On Mon, May 5, 2008 at 9:27 PM, Kevin Kargel wrote: > WIPO refers to "Internet Address" synonomously with "Domain Name" and > defines it as a "human friendly form" of the numeric Internet Protocol > address. > > WIPO came dangerously close to making a statement about IP numerical > addressing as property in > http://www.wipo.int/amc/en/processes/process1/rfc/3/interim2_ch1.html Can you tell us which passage you are referring to? I don't see any such statement in the above page (close or not). -- Cheers, McTim $ whois -h whois.afrinic.net mctim From kkargel at polartel.com Mon May 5 15:04:25 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 5 May 2008 14:04:25 -0500 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <015c01c8aee0$e8543840$6fce4b41@tedsdesk> References: <70DE64CEFD6E9A4EB7FAF3A063141066A106BA@mail> <015c01c8aee0$e8543840$6fce4b41@tedsdesk> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A106BC@mail> >> Imagine if WIPO found IP addresses were property and subject to copyright. >> Based on that precident you would have a perfect argument for saying that telephone numbers are also property. So now when a business >> moves cross country their phone number including the area code is required to go with them. Ah, but the telephone issue has already been decided, and telco's are required to let you keep your number and area code.. This is not to say you will avoid toll charges by carrying a specific area code with you, but it does say you can do it if you want to.. http://www.fcc.gov/cgb/consumerfacts/numbport.html In this document the FCC goes so far as to say "your old company may not refuse to port your number, even if you owe money " So it looks like telephone numbers are defacto property.. Which probably sets a precedent for IP addresses.. This is rather the reverse of your discussion, but still applicable.. From michel at arneill-py.sacramento.ca.us Mon May 5 15:08:27 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 5 May 2008 12:08:27 -0700 Subject: [arin-ppml] fair warning: less than 1000 days left to IPv4 exhaustion Message-ID: 3:147 From michel at arneill-py.sacramento.ca.us Mon May 5 15:08:27 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 5 May 2008 12:08:27 -0700 Subject: [arin-ppml] fair warning: less than 1000 days left to IPv4 exhaustion Message-ID: 3:145 From michel at arneill-py.sacramento.ca.us Mon May 5 15:08:28 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 5 May 2008 12:08:28 -0700 Subject: [arin-ppml] fair warning: less than 1000 dayslefttoIPv4exhaustion Message-ID: 3:148 From michel at arneill-py.sacramento.ca.us Mon May 5 15:08:28 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 5 May 2008 12:08:28 -0700 Subject: [arin-ppml] Legacy Space authority Message-ID: 3:150 From michel at arneill-py.sacramento.ca.us Mon May 5 15:08:28 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 5 May 2008 12:08:28 -0700 Subject: [arin-ppml] Legacy Space authority Message-ID: 3:149 A non-text attachment was scrubbed... Name: ATT00907.txt Type: application/octet-stream Size: 382 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Mon May 5 15:08:29 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 5 May 2008 12:08:29 -0700 Subject: [arin-ppml] Legacy Space authority Message-ID: 3:146 From michel at arneill-py.sacramento.ca.us Mon May 5 15:08:29 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 5 May 2008 12:08:29 -0700 Subject: [arin-ppml] Legacy Space authority Message-ID: 3:151 From tedm at ipinc.net Mon May 5 15:11:08 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 May 2008 12:11:08 -0700 Subject: [arin-ppml] fair warning: less than 1000days lefttoIPv4 exhaustion In-Reply-To: Message-ID: <016201c8aee3$c6527100$6fce4b41@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of > Dan.Thorson at seagate.com > Sent: Monday, May 05, 2008 11:37 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] fair warning: less than 1000days > lefttoIPv4 exhaustion > > > I apologize in advance, and perhaps I'm missing the entire > point... but I think it's all a bit absurd that many of the > participants of this email list think that we should all be > migrating to IPv6 today, and that if we're not already > in-process then woe-be-to-me. For an enterprise customer's > perspective things look a bit different. Here's a response I > received from one of the most well known telecommunication > providers in the USA (when asked about providing IPv6 BGP > peering across our Internet circuit) > > "Commercial products are expected to become available > starting in 2009. For MIS in particular, Current plans are > for IPv6 to be made available on a limited basis on MIS in > 1Q09 with general availability scheduled for 4Q09." > Remember the US government has a deadline of this year for IPv6 from it's vendors. That is why your seeing this. > So: a huge ISP/telecom provider in the US is saying they'll > provide IPv6 to me in about 18 months. A query to one of my > other upstreams provided this: > > "We are currently evaluating our IPv6 solution in our lab, > but it is not something that we offer today. We will be > making a decision of general availability at the beginning of > Q3 2008." > > So this smaller ISP (with reach in to a reasonable fraction > of the US) will THINK about availability in a few months. > That's not any kind of guarantee that they actually WILL provide it. > They probably won't. A smaller ISP likely has no government contracts. Thus they will likely have no existing customers that will demand IPv6. > So I please beg everybody's pardon when I say, speaking ONLY > for me (and not my company), that I do not have any sense of > urgency re: an IPv6 conversion/rollout, since clearly my > upstreams don't have any. > But you see, you don't have any choice. Since your upstreams don't provide it YOU CAN'T provide it EVEN IF you had a sense of urgency. (unless you wanted to get involved with a tunnel provider, yuck) So why would you, being I'm assuming a somewhat logical person, start jumping up and down and having a heart attack over something that you cannot change? > I suspect the biggest problem will be for the company which > opens their doors in 3 years, and tries to get IP space, and > finds that they can only get IPv6... and then discovers that > only a fraction of the people on the Internet can reach their > www site. THEN it's gonna hit the fan. > I think this is VERY UNLIKELY. Any company that opens it's doors in 3 years is either going to be small, in which case they get IP numbering from their ISP and NOT from the RIRs - OR they are going to be a massively largely funded venture capitalized firm that has clueful people involved in the business plan who are going to know about this stuff and know about the workarounds long before getting any rude awakenings. The small fry if they need IPv4 they will just go shopping for a different ISP if the one that they have can't provide it. The large fry are going to do what the large fry always do - which is spend money on a workaround (getting IPv4 from an ISP that has it) or forcing the rest of the world to do things the way they want them done. (ie: use IPv6) I think the biggest problem will be the medium-sized ISPs who are not big enough to have the money to force the rest of the world to do things their way, yet are large enough that they have growing and pressing needs for IPv4. Those folks will have to get involved in proxying IPv6<->IPv4 and such, and God help them if they can't get their customers to go along with them. But, it's not like ARIN didn't forcibly subscribe all those medium-sized fry to this mailing list - and I recall a flood of unsubscribe requests after that. Well, if those people refuse to be educated and prefer to stick their head in the sand on this, then piss on them. Ted From tedm at ipinc.net Mon May 5 15:14:23 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 May 2008 12:14:23 -0700 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: Message-ID: <016301c8aee4$3a43fd90$6fce4b41@tedsdesk> > -----Original Message----- > From: Bill Darte [mailto:BillD at cait.wustl.edu] > Sent: Monday, May 05, 2008 11:59 AM > To: Ted Mittelstaedt; Geoff Huston; Paul Vixie > Cc: ppml at arin.net > Subject: RE: [arin-ppml] fair warning: less than 1000 days > lefttoIPv4 exhaustion > > > > > > -----Original Message----- > > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > Sent: Monday, May 05, 2008 12:40 PM > > To: Bill Darte; 'Geoff Huston'; 'Paul Vixie' > > Cc: ppml at arin.net > > Subject: RE: [arin-ppml] fair warning: less than 1000 days > > lefttoIPv4 exhaustion > > > > > > > The range 1.5-4.5 is perhaps scarier.... > > > > To whom? > > > > You know the interesting thing about this is that the ONLY > > people who are scared about IPv4 runout are those who have a > > GROWING need for IP addresses. > > The law of unintended consequences affects not only primarly > players in change. Preparations for business as usual is > always a strategic problem. Not engaging the issue of IPv4 > runout and IPv6 adoption, changed transfer policy and > perterbations in the governance roles of the Internet are > issues that 'may' make an impact on organizations and > individuals not matter how hard they try to ignore them...I'm > thinking. > Very good point. But the obvious unintended consequence of an IPv4-only policy for an organization is when someone goes online with an IPv6-only site that one of the IPv4-only orgs customers wants to get to, that customer will be naturally upset. And so far, the "IPv6-only, you cannot connect to us if your IPv4" swimming pool is empty, with a big crowd of dual-stacked orgs standing around the edge, daring each other to jump in first. Ted From bonomi at mail.r-bonomi.com Mon May 5 15:55:07 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 5 May 2008 14:55:07 -0500 (CDT) Subject: [arin-ppml] Legacy Space authority Message-ID: <200805051955.m45Jt7uC009741@mail.r-bonomi.com> > Date: Mon, 5 May 2008 14:04:25 -0500 > From: "Kevin Kargel" > Subject: Re: [arin-ppml] Legacy Space authority > > >> Imagine if WIPO found IP addresses were property and subject to > >> copyright. > >> Based on that precident you would have a perfect argument for saying > >> that telephone numbers are also property. So now when a business > >> moves cross country their phone number including the area code is > >> required to go with them. > > Ah, but the telephone issue has already been decided, and telco's are > required to let you keep your number and area code.. FALSE TO FACT. _Read_ the document you cite. I quote: "If you are moving from one geographic area to another, however, you may not be able to take your number with you. > This is not to say > you will avoid toll charges by carrying a specific area code with you, > but it does say you can do it if you want to.. > http://www.fcc.gov/cgb/consumerfacts/numbport.html > > In this document the FCC goes so far as to say "your old company may not > refuse to port your number, even if you owe money " > > So it looks like telephone numbers are defacto property.. Which > probably sets a precedent for IP addresses.. This is rather the reverse > of your discussion, but still applicable.. FALSE TO FACT. again. It has been held, by the FCC and the courts enforcing the rules, that telephone numbers are _not_ "property" of the telephone company. Neither are they property of the consumer who uses that number. _LIKE_ IP addresses, they are a unique resource from a "limited-size, shared-resource pool" -- where that pool is distributed over a limited geographic area. If you don't pay your bill, your current 'TSP' (telephone service provider) _can_ terminate your services. *WHEN* service is terminated, you lose any right and interest you had in the phone number -- unless a 'change of provider' was _already_ in process. If your new TSP of choice doesn't have an actual presense in the same local geographic area as your prior provider, you _cannot_ have that number handled by _that_ TSP. For telephony, there _is_ a *strict* 'geographic-based' allocation scheme 'under the covers', based not on just area-codes, but also "LATA boundaries", and 'rate centers'. Whatever rights you -- a customer -- may have with regard to a specific phone number, those rights apply *ONLY* _within_ the geographic locale to which that number is irretrievably bound. The parallel between IP addresses and telephone numbers _is_ an interesting one. There *is* a central authority for each telephone 'region' in the world (which is functionally similar to the IPv4 RIRs) -- which allocates 'regionally unique' resources (area codes _and_ telephone number address-blocks) based on demonstrated need. ONCE numbers are allcoated, this 'telephone number registry' (TNR) has no further control over how they are used. The TSPs that recieve these 'address-block' allocations from the TNR are free to assign them to customers for that customer's, temporary, and exclusive, use. TSPs _do_ have the legal right to assign different numbers to you, and revoke the ones you -were- using. (Exactly the same as a 'forced re-assignment' of an IP address-block received from your ISP's allocation.) [ aside, I have personally experienced this with residential phone service -- *NOT* a result of an area-code split, but simply an involuntary assignment to a new 'exchange' (in the same rate center) and getting an entirely new 7 digits for the number. If, at any time, you, the customer, _stop_ paying the 'rent' on your telephone number, control of that number reverts to the TSP that was providing you service. _They_ are free to re-assign it to a new/different customer of theirs, and you -- the former customer -- have *NOTHING* to say about it. _IF_ the telephone number is viewed as 'property', then it is 'owned' by the serviceing telephone company, subject to the 'deed restriction' on the local in which it can be used, *AND* the 'lessee' has the 'right' to force the current owner to 'sell' that "property" to the landlord/lessor of the _lessee's_ choice. *INTERESTINGLY* this 'property transfer' takes place =without= any compensation to the selling party. This fact is one of the strongest arguments that a phone number is _not_ property. A 'porting' of a phone number to a different carrier *IS* a 'taking' of a thing of value to the old carrier, and since it is being done 'by force of law', would quite likely run afoul of the Constitutional prohibition on 'takings' -- unless the thing is _not_ property. From kkargel at polartel.com Mon May 5 16:20:50 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 5 May 2008 15:20:50 -0500 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <200805051955.m45Jt7uC009741@mail.r-bonomi.com> References: <200805051955.m45Jt7uC009741@mail.r-bonomi.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A106C1@mail> >> Ah, but the telephone issue has already been decided, and telco's are >> required to let you keep your number and area code.. >FALSE TO FACT. _Read_ the document you cite. I quote: > "If you are moving from one geographic area to another, however, you may > not be able to take your number with you. Yes, this is true. If you move from one area code to another at least within the same geographic area you will be able to take the number. Also, the statement you included says "you may not be able to", which infers "you may be able to".. What it says to my reading is that if it is technically possible to port the number then you will be able to port the number. The statement you cited is an out for the telco's so that they are not required to perform the impossible. People are moving from state to state and taking their cel numbers with them. This is even happening across a span of more than one state. I don't know what the definition of "geographical area" is, but I assume it has something to do with the reach ond interoperability of the telco switching networks. Perhaps a more technically educated telco tech can fill in the gaps for us. This doesn't change that if even one person moves from one telco to another (whether or not he moves physically) and he has the capability to demand to keep his number - without regard to the wishes of his telco - then the number in question is being treated as property with value. This all is of course my humble personal opinion only, legal and binding only so far as I can throw it. From owen at delong.com Mon May 5 16:35:50 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 5 May 2008 16:35:50 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A106C1@mail> References: <200805051955.m45Jt7uC009741@mail.r-bonomi.com> <70DE64CEFD6E9A4EB7FAF3A063141066A106C1@mail> Message-ID: <4BC09070-B2CB-4F95-9866-50F70C1BA374@delong.com> > People are moving from state to state and taking their cel numbers > with > them. This is even happening across a span of more than one state. I > don't know what the definition of "geographical area" is, but I assume > it has something to do with the reach ond interoperability of the > telco > switching networks. Perhaps a more technically educated telco tech > can > fill in the gaps for us. > The number isn't being moved from state to state in this instance (from a telco technology perspective). Cellular service is a bit whacky in that you're dealing with an entirely different network that is sort of overlaid on the same geographic area, but, mostly separate with lots of common touch points to the PSTN. If you have a 408, for example cell phone, but, you take it with you to VA (703, for example) or move to VA and keep the number, calls from the PSTN to your cell phone will (regardless of where you are) get hot-potatoed to the closest PSTN->Cell Provider hand-off point for your given Cell provider, or, they will get routed to a hand-off point in your original area code (depending on the setup between the PSTN provider and Cell provider in question). I believe the latter is the more common occurrence. > This doesn't change that if even one person moves from one telco to > another (whether or not he moves physically) and he has the capability > to demand to keep his number - without regard to the wishes of his > telco - then the number in question is being treated as property with > value. > For that to be true, you would have to pretend that the end-user was the OWNER of the number, and, that simply isn't the case. The end-user is, at best, a tenant in the number and this represents a bizarre extension of tenant's rights. Owen From bonomi at mail.r-bonomi.com Mon May 5 17:30:34 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 5 May 2008 16:30:34 -0500 (CDT) Subject: [arin-ppml] Legacy Space authority Message-ID: <200805052130.m45LUY15010572@mail.r-bonomi.com> > Date: Mon, 5 May 2008 15:20:50 -0500 > From: "Kevin Kargel" > To: > Subject: Re: [arin-ppml] Legacy Space authority > > >> Ah, but the telephone issue has already been decided, and telco's are > > >> required to let you keep your number and area code.. > > >FALSE TO FACT. _Read_ the document you cite. I quote: > > "If you are moving from one geographic area to another, however, you > may > > not be able to take your number with you. > > Yes, this is true. If you move from one area code to another at least > within the same geographic area you will be able to take the number. I say again, "FALSE TO FACT". a) that 7-digit number may already be in use in the destination NPA. b) the porting rules require *LOCAL* number portability only. that's why it is called "Local Number Portability", aka LNP. c) "local" is defined as "within the same rate center", which, by definition means it is restricted to a single area-code. The concept of "rate- centers" was developed -before- 'overlay' area-codes existed, and there is a built-in assumption of a hierarchical structure, where a rate center is part of a single area-code only. This can result in two rate centers, in different area codes, being 'zero miles' apart. > Also, the statement you included says "you may not be able to", which > infers "you may be able to".. What it says to my reading is that if it > is technically possible to port the number then you will be able to port > the number. What you read, and how it is interpreted in the real world, by the people who do it, is different. :) If the 'new' carrier does not have a physical point of presence in the same rate center at the C.O. of the 'old' carrier that the number is currently served out of, the number is *NOT* transferable to that company. Don't take my word for it, ask the FCC. In theory, it may be "possible" in some circumstances, but the laws and FCC regulations do -not- require it. Since it is not 'required', it is, in virtually all instances 'administratively denied'. When a thing is _not_ required, you have no recourse if the other party "chooses not to" do it. > People are moving from state to state and taking their cel numbers with > them. This is even happening across a span of more than one state. No, they are _NOT_. They are 'roaming' within the cellular network. The physical address for the service (where the call is handed off to the PSTN) remains unchanged. If a person with a (208) area cell-phone moves to Washington, D.C., and keeps their old number, when they're at 8th and I, and somebody calls them from 4th and K, it is billed as a long distance call _to_Idaho_. In fact, the call is _routed_ to Idaho over the PSTN, and then back-hauled to where the cell customer is over the wireless carrier's private bandwidth. (there _may_ be 'special case' handling if the calling party is a cellular caller with service from the same provider as the called party uses. Repeat, "may" be, not necessarily 'is'.) Also, a "billing address" is unconnected to the 'service address'. For larger businesses, it is not at all uncommon for the billing to go to 'headquarters', many states away from the regional office. this discontinuity between the billing address and the point of connection to the PSTN is irrelevant to phone network routing. > I don't know what the definition of "geographical area" is, but I assume > it has something to do with the reach ond interoperability of the telco > switching networks. You assume wrongly. :) > Perhaps a more technically educated telco tech can > fill in the gaps for us. You didn't listen to the telco guru. I've been a telephony manager. I've done number porting. I've fought the battles when the carriers screwed it up. It all has to do with how distance-based billing (originally long-distance) charges are calculated. Telco's have POP (switching facilities, known as a "Central Office", or C.O.) in _lots_ of places. What was regarded as 'too many' places to calculate distances between every pair of C.O.s in the nation, to establish a mileage charge for calls between those two C.O.'s. Hence C.O.'s within some degree of physical proximity were grouped into a single 'rate center'. And distances were computed _only_ between pairs of "rate centers". This also had the advantage of being able to be done _once_, and the results "cast in stone". When a new C.O. was brought on line, it was assigned (for billing purposes) to the _already-existing_ rate-center that covered the area it served. You can "port" a phone number only within the rate-center where the number is billed. And then only within the same NPA ("area code" to the average person). The latter restriction prohibits multiple people holding the same 7-digit string in different NPAs from moving into a single vicinity and fighting about who has to give up 'their' number. > This doesn't change that if even one person moves from one telco to > another (whether or not he moves physically) and he has the capability > to demand to keep his number - without regard to the wishes of his > telco - then the number in question is being treated as property with > value. Sorry, you're wrong. _If_ it is property, it is -not- the customer's property. If it were customer property, he would not have to pay rent to continue to retain the rights to he number. He would have to pay to _use_ the number, but not to simply retain it (not in active use). And 'control' over that number would not _revert_ to the telephone company that was the last one to supply that customer with service for it. The party that manages telephone number block assignments in the U.S does it as a contractor for the FCC, with the costs of those contracted services are paid for by assessments levied on telephone service providers in a manner specified in FCC rules. From kkargel at polartel.com Mon May 5 17:35:41 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 5 May 2008 16:35:41 -0500 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <200805052130.m45LUY15010572@mail.r-bonomi.com> References: <200805052130.m45LUY15010572@mail.r-bonomi.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A106C7@mail> Read it again.. They are transporting the ten digit number.. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert Bonomi Sent: Monday, May 05, 2008 4:31 PM To: ppml at arin.net Subject: Re: [arin-ppml] Legacy Space authority > Date: Mon, 5 May 2008 15:20:50 -0500 > From: "Kevin Kargel" > To: > Subject: Re: [arin-ppml] Legacy Space authority > > >> Ah, but the telephone issue has already been decided, and telco's > >> are > > >> required to let you keep your number and area code.. > > >FALSE TO FACT. _Read_ the document you cite. I quote: > > "If you are moving from one geographic area to another, however, > >you > may > > not be able to take your number with you. > > Yes, this is true. If you move from one area code to another at least > within the same geographic area you will be able to take the number. I say again, "FALSE TO FACT". a) that 7-digit number may already be in use in the destination NPA. b) the porting rules require *LOCAL* number portability only. that's why it is called "Local Number Portability", aka LNP. c) "local" is defined as "within the same rate center", which, by definition means it is restricted to a single area-code. The concept of "rate- centers" was developed -before- 'overlay' area-codes existed, and there is a built-in assumption of a hierarchical structure, where a rate center is part of a single area-code only. This can result in two rate centers, in different area codes, being 'zero miles' apart. > Also, the statement you included says "you may not be able to", which > infers "you may be able to".. What it says to my reading is that if > it is technically possible to port the number then you will be able to > port the number. What you read, and how it is interpreted in the real world, by the people who do it, is different. :) If the 'new' carrier does not have a physical point of presence in the same rate center at the C.O. of the 'old' carrier that the number is currently served out of, the number is *NOT* transferable to that company. Don't take my word for it, ask the FCC. In theory, it may be "possible" in some circumstances, but the laws and FCC regulations do -not- require it. Since it is not 'required', it is, in virtually all instances 'administratively denied'. When a thing is _not_ required, you have no recourse if the other party "chooses not to" do it. > People are moving from state to state and taking their cel numbers > with them. This is even happening across a span of more than one state. No, they are _NOT_. They are 'roaming' within the cellular network. The physical address for the service (where the call is handed off to the PSTN) remains unchanged. If a person with a (208) area cell-phone moves to Washington, D.C., and keeps their old number, when they're at 8th and I, and somebody calls them from 4th and K, it is billed as a long distance call _to_Idaho_. In fact, the call is _routed_ to Idaho over the PSTN, and then back-hauled to where the cell customer is over the wireless carrier's private bandwidth. (there _may_ be 'special case' handling if the calling party is a cellular caller with service from the same provider as the called party uses. Repeat, "may" be, not necessarily 'is'.) Also, a "billing address" is unconnected to the 'service address'. For larger businesses, it is not at all uncommon for the billing to go to 'headquarters', many states away from the regional office. this discontinuity between the billing address and the point of connection to the PSTN is irrelevant to phone network routing. > I don't know what the definition of "geographical area" is, but I > assume it has something to do with the reach ond interoperability of > the telco switching networks. You assume wrongly. :) > Perhaps a more technically educated telco tech > can fill in the gaps for us. You didn't listen to the telco guru. I've been a telephony manager. I've done number porting. I've fought the battles when the carriers screwed it up. It all has to do with how distance-based billing (originally long-distance) charges are calculated. Telco's have POP (switching facilities, known as a "Central Office", or C.O.) in _lots_ of places. What was regarded as 'too many' places to calculate distances between every pair of C.O.s in the nation, to establish a mileage charge for calls between those two C.O.'s. Hence C.O.'s within some degree of physical proximity were grouped into a single 'rate center'. And distances were computed _only_ between pairs of "rate centers". This also had the advantage of being able to be done _once_, and the results "cast in stone". When a new C.O. was brought on line, it was assigned (for billing purposes) to the _already-existing_ rate-center that covered the area it served. You can "port" a phone number only within the rate-center where the number is billed. And then only within the same NPA ("area code" to the average person). The latter restriction prohibits multiple people holding the same 7-digit string in different NPAs from moving into a single vicinity and fighting about who has to give up 'their' number. > This doesn't change that if even one person moves from one telco to > another (whether or not he moves physically) and he has the capability > to demand to keep his number - without regard to the wishes of his > telco - then the number in question is being treated as property with > value. Sorry, you're wrong. _If_ it is property, it is -not- the customer's property. If it were customer property, he would not have to pay rent to continue to retain the rights to he number. He would have to pay to _use_ the number, but not to simply retain it (not in active use). And 'control' over that number would not _revert_ to the telephone company that was the last one to supply that customer with service for it. The party that manages telephone number block assignments in the U.S does it as a contractor for the FCC, with the costs of those contracted services are paid for by assessments levied on telephone service providers in a manner specified in FCC rules. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From owen at delong.com Mon May 5 18:26:52 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 5 May 2008 15:26:52 -0700 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <200805052130.m45LUY15010572@mail.r-bonomi.com> References: <200805052130.m45LUY15010572@mail.r-bonomi.com> Message-ID: <9F94DDAF-C254-46A9-A94D-6752DCB35282@delong.com> On May 5, 2008, at 2:30 PM, Robert Bonomi wrote: > >> Date: Mon, 5 May 2008 15:20:50 -0500 >> From: "Kevin Kargel" >> To: >> Subject: Re: [arin-ppml] Legacy Space authority >> >>>> Ah, but the telephone issue has already been decided, and telco's >>>> are >> >>>> required to let you keep your number and area code.. >> >>> FALSE TO FACT. _Read_ the document you cite. I quote: >>> "If you are moving from one geographic area to another, however, >>> you >> may >>> not be able to take your number with you. >> >> Yes, this is true. If you move from one area code to another at >> least >> within the same geographic area you will be able to take the number. > > I say again, "FALSE TO FACT". > > a) that 7-digit number may already be in use in the destination NPA. > > b) the porting rules require *LOCAL* number portability only. > that's why > it is called "Local Number Portability", aka LNP. > > c) "local" is defined as "within the same rate center", which, by > definition > means it is restricted to a single area-code. The concept of > "rate- > centers" was developed -before- 'overlay' area-codes existed, > and there > is a built-in assumption of a hierarchical structure, where a > rate center > is part of a single area-code only. This can result in two rate > centers, > in different area codes, being 'zero miles' apart. > This is not true. For example, 530 and 916 are the same rate center. Also, 310, 213, and, I believe a couple of others are in the same rate center. These are what is known as "overlay area codes", and, in those locations, you can have LNP even if all your neighbors have a different area code so long as you stay within the bounds of the rate center. >> Also, the statement you included says "you may not be able to", which >> infers "you may be able to".. What it says to my reading is that >> if it >> is technically possible to port the number then you will be able to >> port >> the number. > > What you read, and how it is interpreted in the real world, by the > people > who do it, is different. :) > > If the 'new' carrier does not have a physical point of presence in the > same rate center at the C.O. of the 'old' carrier that the number is > currently served out of, the number is *NOT* transferable to that > company. > Don't take my word for it, ask the FCC. > True, but, finding a major cellular carrier that doesn't have a physical presence in your rate center isn't exactly easy in most cases. Then, once you've moved it from land-line to cellular, you can, generally move it anywhere in the country for all practical purposes. > In theory, it may be "possible" in some circumstances, but the laws > and > FCC regulations do -not- require it. Since it is not 'required', it > is, > in virtually all instances 'administratively denied'. When a thing > is _not_ > required, you have no recourse if the other party "chooses not to" > do it. > See my previous paragraph. I know a number of people who have used this as a workaround. >> People are moving from state to state and taking their cel numbers >> with >> them. This is even happening across a span of more than one state. > > No, they are _NOT_. They are 'roaming' within the cellular network. > The > physical address for the service (where the call is handed off to > the PSTN) > remains unchanged. If a person with a (208) area cell-phone moves to > Washington, D.C., and keeps their old number, when they're at 8th > and I, > and somebody calls them from 4th and K, it is billed as a long > distance call > _to_Idaho_. In fact, the call is _routed_ to Idaho over the PSTN, > and then > back-hauled to where the cell customer is over the wireless > carrier's private > bandwidth. (there _may_ be 'special case' handling if the calling > party is > a cellular caller with service from the same provider as the called > party uses. > Repeat, "may" be, not necessarily 'is'.) > Who cares. Long distance within the CONUS is free if you aren't voluntarily paying stupid rates these days, so, what does it matter how much it is backhauled? The extra 20ms doesn't really seem to affect call quality. > It all has to do with how distance-based billing (originally long- > distance) > charges are calculated. > Well, had would be a better phrase. These days, I know very few people other than on business land-lines who pay for long-distance calls within the CONUS. Most business pay low enough rates for them that they simply don't care about the costs. It used to be that long distance charges mattered. Today, they have dropped to a level where they are mostly regarded as noise, and, indeed, I think mostly go to pay for the cost of metering them and producing the bills more than to maintaining the actual network. > > You can "port" a phone number only within the rate-center where the > number > is billed. And then only within the same NPA ("area code" to the > average > person). The latter restriction prohibits multiple people holding > the same > 7-digit string in different NPAs from moving into a single vicinity > and > fighting about who has to give up 'their' number. > Right, but, in rate centers with multiple NPAs, you can move your NPANXXSFXX anywhere within that rate center without changing your NPA. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jradel at vantage.com Mon May 5 19:05:53 2008 From: jradel at vantage.com (Jon Radel) Date: Mon, 05 May 2008 19:05:53 -0400 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A106C1@mail> References: <200805051955.m45Jt7uC009741@mail.r-bonomi.com> <70DE64CEFD6E9A4EB7FAF3A063141066A106C1@mail> Message-ID: <481F92D1.50406@vantage.com> Kevin Kargel wrote: > > Yes, this is true. If you move from one area code to another at least > within the same geographic area you will be able to take the number. > Of course not. What's the point of things like overlay NPAs if everyone has to reserve all numbers in use in the first one for people who want to move to the other NPA. All portability applies only to the full 10 digits. You are, of course, free to request your favorite 7-digits whenever you get a new number, and most phone companies will make an attempt to accommodate you. > People are moving from state to state and taking their cel numbers with > them. This is even happening across a span of more than one state. I > don't know what the definition of "geographical area" is, but I assume > it has something to do with the reach ond interoperability of the telco > switching networks. Perhaps a more technically educated telco tech can > fill in the gaps for us. > > The only real answer is "it depends." If you move your service to a LEC (Local Exchange Carrier) or wireline per the FCC document you referenced, generally you have to have service physically delivered to an address within the confines of the rate center. Sometimes you have to be even more precise (as of when I had to clean up a mess a few years ago, Arlington and Alexandria in Va. shared a rate center, but if you got the wrong NXX for the side of the city border, E911 wouldn't work right) and other times entire NPAs are a single rate center (202, 212, 646, and so on). Generally, however, if the phone number and the service address don't match, the LEC won't even talk to you. VOIP has made quite a mess of this, because unlike a POTS line, where you can't pick your phone up and move it, or a T1 to your PBX, where you sorta could, but it'd be a big production, with VOIP you can generally unplug your phone, take it across the country, and plug it in again. Suddenly you've butchered the whole concept of local vs long-distance (which I rarely catch people getting upset about) *and* E911 does not work, not one little bit (which freaks a fair number of people). There are ways of dealing with the latter, but currently they're pretty much kludges and the real fixes aren't really quite here yet. Very much a moving target. Incidentally, even if a VOIP provider isn't a LEC, somewhere in the background there's a LEC that probably insisted on a valid service address before the number was put in service. Of course, I know somebody at one provider who when he had a customer who wanted to look big by having local numbers all over would just use the addresses of the nearest Kinkos for all the number orders. Wireless is very, very different, and outside my area of expertise. There you can generally go tripping all over the country (or world, really, though that can get a touch expensive), and my personal experience is that the carriers no longer fuss at you if your NPA and billing address don't match like they did many years ago. However, the flexibility here has no applicability to the wireline world. You can port your wireline number to your wireless service, move across the country, and all is probably going to work out fine. You will *not* be able to port the number back to a wireline in your new location. --Jon Radel Whose current employer is not featured in any of the above examples! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3303 bytes Desc: S/MIME Cryptographic Signature URL: From tedm at ipinc.net Mon May 5 19:19:01 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 May 2008 16:19:01 -0700 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <481F92D1.50406@vantage.com> Message-ID: <017e01c8af06$67775ec0$6fce4b41@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jon Radel > Sent: Monday, May 05, 2008 4:06 PM > To: Kevin Kargel > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Legacy Space authority > > > > VOIP has made quite a mess of this, because unlike a POTS > about) *and* E911 does not work, not one little bit (which > freaks a fair number of people). Yeah, I know - before 911 the hospital emergency rooms were like ghost towns because everyone who was injured, died before they could figure out how to dial the ambulance. (eye roll) People might even have to go back to writing the police department phone number on their phone with Magic Marker, like in the old days. Oh, the horrors! So, is VoIP technologies answer to Natural Selection? ;-) Ted From jcurran at istaff.org Mon May 5 21:24:06 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 5 May 2008 21:24:06 -0400 Subject: [arin-ppml] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <016201c8aee3$c6527100$6fce4b41@tedsdesk> References: <016201c8aee3$c6527100$6fce4b41@tedsdesk> Message-ID: At 12:11 PM -0700 5/5/08, Ted Mittelstaedt wrote: > >Any company that opens it's doors in 3 years is either going to be >small, in which case they get IP numbering from their ISP and >NOT from the RIRs >... >The small fry if they need IPv4 they will just go shopping for a >different ISP if the one that they have can't provide it. At the moment of RIR IPv4 depletion, there'll will be variation among individual ISPs in the amount of IPv4 space remaining for new customer growth (based on the time and size of their last allocation per NRPM 4.2.2 or 4.2.4). Given the limited customer benefits of IPv6, customers are likely to value the status quo and seek ISPs who still have available IPv4 space just as you noted above. However, one would expect these ISPs to deplete their last allocation at an accelerated pace and (in the absence of some alternative solution) wouldn't this make ISP shopping for IPv4 simply a transient condition? /John (the above are purely my own personal musings on the topic) From michael.dillon at bt.com Tue May 6 03:03:36 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 May 2008 08:03:36 +0100 Subject: [arin-ppml] Legacy Space authority In-Reply-To: <014e01c8aeda$4223dfd0$6fce4b41@tedsdesk> References: <014e01c8aeda$4223dfd0$6fce4b41@tedsdesk> Message-ID: > Your arguing that IP addressing is property, and property is > subject to future legal decisions of a court which will end > up proving that IP addressing is property. No I'm not. It's pretty clear that IP addresses are not property in the normal sense, i.e. you cannot buy and sell them freely. But in another sense, they are the property of the RIRs collectively to allocate as they see fit. This is the thing that could potentially be disputed under international law, if the RIRs are seen as being unfair in their allocation of this valuable property. The issue has already come up in the WSIS meetings. > The ICJ in The Hague is extremely unlikely to take up an IP > addressing case until WIPO has weighed in on it. And I find > that very unlikely, if they were going to do that, they would > have done it when they extended copyright over Internet domain names. ICJ and WIPO only scratch the surface of the international organizations which might weigh in if they see a weakness in the system. --Michael Dillon From michael.dillon at bt.com Tue May 6 03:13:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 May 2008 08:13:10 +0100 Subject: [arin-ppml] fair warning: less than 1000days lefttoIPv4 exhaustion In-Reply-To: References: <014d01c8aed7$11b93050$6fce4b41@tedsdesk> Message-ID: > I suspect the biggest problem will be for the company which > opens their doors in 3 years, and tries to get IP space, and > finds that they can only get IPv6... and then discovers that > only a fraction of the people on the Internet can reach their > www site. THEN it's gonna hit the fan. IT is pretty simple for an IPv6-only webserver to provide access to the IPv4 Internet. I would expect that any ISP providing IPv6 hosting access, would implement the neccesary gateway services. In any case, even enterprises need to do test deployments of IPv6 before they go live with it, and that is the kind of work that people need to do today. You will notice that the ISPs all said that they are doing their testing RIGHT NOW in order to be prepared for full commercial services sometime in the next year and a half. That is because they MUST be ready to sell IPv6 before IPv4 runs out otherwise there will be hell to pay with their shareholders. No rational person is advising people to rush out and convert to IPv6 today. We are recommending that you begin using IPv6 in trial deployments in order to find out what you really need to do when the conversion begins in earnest. --Michael Dillon From iljitsch at muada.com Tue May 6 04:13:37 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 May 2008 10:13:37 +0200 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: References: <70031.1209831769@sa.vix.com> <481D2739.1060605@apnic.net> Message-ID: <7F5C6FDA-495D-402E-98F9-163D00CC2DED@muada.com> On 5 mei 2008, at 9:59, wrote: > Last year, less than 300 days ago, this counter showed 1300 days > and it was publicised a lot. I checked it several months later and > the number had gone up to more than 1400, I believe. Now suddenly it > is down to 1000!!! > It almost seems like we consume addresses slower than average for a > while, then a large allocation goes out and we have suddenly > consumed more than the average amount. Almost... This is the amount of address space given out per month the last 16 months: +---------+--------+--------+ | month | allocs | Maddrs | +---------+--------+--------+ | 2007-01 | 436 | 18.12 | | 2007-02 | 459 | 16.92 | | 2007-03 | 572 | 21.25 | | 2007-04 | 511 | 10.24 | | 2007-05 | 559 | 20.02 | | 2007-06 | 488 | 19.61 | | 2007-07 | 493 | 21.28 | | 2007-08 | 471 | 17.02 | | 2007-09 | 518 | 8.54 | | 2007-10 | 572 | 14.41 | | 2007-11 | 500 | 13.55 | | 2007-12 | 1337 | 15.86 | | 2008-01 | 501 | 7.66 | | 2008-02 | 537 | 23.03 | | 2008-03 | 523 | 13.28 | | 2008-04 | 980 | 28.18 | +---------+--------+--------+ As you can see, the difference between months can be almost a factor 4. Looking at just the allocations of 1048576 addresses or more (/12) the difference is even bigger: +---------+--------+--------+ | month | allocs | Maddrs | +---------+--------+--------+ | 2007-01 | 6 | 9.96 | | 2007-02 | 2 | 5.24 | | 2007-03 | 8 | 13.48 | | 2007-04 | 2 | 3.41 | | 2007-05 | 5 | 11.53 | | 2007-06 | 6 | 11.53 | | 2007-07 | 7 | 14.68 | | 2007-08 | 4 | 9.96 | | 2007-09 | 1 | 2.10 | | 2007-10 | 2 | 4.19 | | 2007-11 | 3 | 5.24 | | 2007-12 | 25 | 12.06 | | 2008-01 | 1 | 1.05 | | 2008-02 | 7 | 13.63 | | 2008-03 | 2 | 3.15 | | 2008-04 | 18 | 18.24 | +---------+--------+--------+ (The "allocs" number isn't completely accurate as I need to insert fake negative allocations to compensate for ARIN's backdating behavior.) This data really doesn't allow for many conclusions, except that things keep going up on average. > Since we have no way of knowing when larger allocations will happen > perhaps the 1.5 year figure is more likely than the 3 year figure. No, 1.5 years is almost impossible. There are still 1.05 billion IPv4 addresses unused in the IANA and RIR pools, burning those up at 700 million per year while we did 196 last year and 73 so far this year doesn't really follow. > In any case, the exact runout date is irrelevant. What is more > important is knowing the nearest possible date for runout since that > is the date you want to target with your IPv6 readiness plans. If > you are IPv6 ready in 1.5 years, then it doesn't matter when IPv4 > addresses run out. If you need 3 years to become IPv6 ready, then > you have a problem. If you need 3 years you really have to start TODAY. And even then you may run into some trouble, but probably not. But don't forget that the IPv4 internet won't grind to a halt when we run out of fresh v4 addresses, it's only the people who need new addresses at that point who'll have trouble. And probably really only the ones who need large blocks. I don't think there will be a time that a /256 will be impossible to get for some time to come, if ever. Turning on v6 on a bunch of routers is fairly trivial. (You do need routers that can forward v6 at full speed, though.) Turning on v6 on a simple server is slightly harder. Doing the same for a massively load balanced / distributed service is somewhat of a challenge. But the real issues are all these little management scripts all over the place that keep businesses running, and the fact that we still don't have any idea how we're going to deploy IPv6 over broadband. I'm really concerned about that part, so far nobody seems interested in solving that issue. From michael.dillon at bt.com Tue May 6 04:28:52 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 May 2008 09:28:52 +0100 Subject: [arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion In-Reply-To: <7F5C6FDA-495D-402E-98F9-163D00CC2DED@muada.com> References: <70031.1209831769@sa.vix.com> <481D2739.1060605@apnic.net> <7F5C6FDA-495D-402E-98F9-163D00CC2DED@muada.com> Message-ID: > Turning on v6 on a bunch of routers is fairly trivial. (You > do need routers that can forward v6 at full speed, though.) > Turning on v6 on a simple server is slightly harder. I'm not sure where you work, but in a typical ISP it is a lot harder to turn on (or off) anything on a router unless it is fixing some kind of urgent problem. Otherwise it has to be tested for months, fully documented, built into monitoring/management systems, and then only done during certain specific quiet hours. Turning on IPv6 on a single server is trivial and probably doesn't even require testing if it is a new server. > Doing > the same for a massively load balanced / distributed service > is somewhat of a challenge. Still easier than turning on IPv6 in a router. You would only do this for new infrastructure since it is intended to handle new traffic. > But the real issues are all these > little management scripts all over the place that keep > businesses running, Yes. Some OSS software suppliers are starting to address this issue since these little management scripts also exist inside commercial software packages. The IP address management systems seem to be leading the pack. Stuff like Men and Mice for instance. > and the fact that we still don't have any > idea how we're going to deploy IPv6 over broadband. I'm > really concerned about that part, so far nobody seems > interested in solving that issue. I don't know what you mean here. DOCSIS 3 already has support for v6 on cable modems, and for DSL we already know that this is a trivial software upgrade for many devices. And forcing consumers to buy a new DSL device is not necessarily a bad thing considering the enhanced features available in wifi, routers, multiport switches, etc. Many ISPs are now beginning to sell enhanced services that come with a DSL device, i.e. TV over Internet or backup services, etc. This is the stuff that product managers are real good at getting done when it needs to get done. --Michael Dillon From info at arin.net Tue May 6 13:10:16 2008 From: info at arin.net (Member Services) Date: Tue, 06 May 2008 13:10:16 -0400 Subject: [arin-ppml] Policy Proposal: Minimum Allocation in the Caribbean Region In-Reply-To: <480F5E60.5060101@arin.net> References: <480F5E60.5060101@arin.net> Message-ID: <482090F8.7030407@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Heather Schiller and Matt Pounsett. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, then the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this 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. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Minimum Allocation in the Caribbean Region > > Author: Cathy Aronson and Paul Andersen > > Proposal Version: Initial > > Submission Date: 23 April 2008 > > Proposal type: New > > Policy term: Renewable > > Policy statement: > > Minimum Allocation. The minimum IPv4 allocation size for ISPs from > the Caribbean portion of the ARIN region is /22. > > 1. Allocation Criteria. > 1. The requesting organization must show the efficient > utilization of an entire previously allocated /22 from their > upstream ISP. This allocation (/22) may have been provided > by an ISP's upstream provider(s), and does not have to be > contiguous address space. The organization must meet the > requirement of efficient use of 4 /24s. > 2. A multi-homed organization must show the efficient > utilization of an entire previously allocated /23 from their > upstream ISP. This allocation (/23) may have been provided > by an ISP's upstream provider(s), and does not have to be > contiguous address space. The organization must meet the > requirement of efficient use of 2 /24s. > 2. Utilization Reporting and Justification. All other ARIN policies > regarding the reporting of justification information for the > allocation of IPv4 and IPv6 address space will remain in effect. > > Rationale: > > ARIN staff have noted that organizations in the Caribbean region have > problems meeting the current criteria due to the fact that the > population in the region is smaller than that of Canada and the US. > There is also a lack of competition with many countries in the region > faced with a monopoly or duopoly situation in terms of transport providers. > > To spur development in the region a similar proposal was passed in this > region for the portion of the African region that ARIN administered > prior to the formation of AfriNIC. This proposal seeks a similar outcome. > > Timetable for implementation: immediate > > From danny at tcb.net Wed May 7 10:01:04 2008 From: danny at tcb.net (Danny McPherson) Date: Wed, 7 May 2008 08:01:04 -0600 Subject: [arin-ppml] Using RPKI to Construct Validated IRR Data Message-ID: <41F80CE2-8600-4E76-B91E-1B0C7D41A815@tcb.net> Folks, I passed this along to a few of the AC folks a month or so back, and the belief was that it made sense but really didn't fit as a official policy proposal, but rather, would be considerd as a recommendation to the AC. I figured I'd post it to the PPML mailing list simply for documentation and discussion purposes, and to allow folks to consider the implications of this on your internal route filtering machinery. Any questions or comments, post'm on the list or let Randy or I know. Also, note that Kurtis presented a near identical proposal at RIPE earlier this week, with Randy as the anchor author, and the slides are available here: Thanks! -danny ----- Using the RPKI to Construct Validated IRR Data Authors: Randy Bush & Danny McPherson Version: 1.0 Date: April 7, 2008 1. Introduction ---------------- This is a proposal to introduce a new registry that augments Internet Routing Registry (IRR) data with the formally verifiable trust model of the Resource Public Key Infrastructure (RPKI) and provide ISPs with the tools to generate an overlay to the IRR which is much more strongly trustable. 2. Summary of current problem ------------------------------ The current methods for adding or updating Internet Routing Registry (IRR) data have weak security, and lack an inherently formally verifiable structure, resulting in a low level of trust in IRR data. To address the problem of this low level of trust in IRR data, there have been proposals to use Resource Public Key Infrastructure (RPKI) to sign IRR data. The problem with most of the proposed schemes, however, is that they are conceptually weak and hard to implement due to the differences between the trust structures of the IRR and the RPKI. More recently, however, Ruediger Volk has described a very simple method of using the RPKI that involves no change to the IRR, software that uses the IRR, or the RPKI. This is a proposal to implement Ruediger Volk's idea to strengthen the operators' use of data in the global IRR. 3. Situation in other RIRs ---------------------------- This proposal has been made in APNIC and RIPE. 4. Details of the proposal ---------------------------- It is proposed that: 4.1 ARIN publish a new IRR that contains 'route' objects generated from Route Origin Authorizations (ROAs) in the RPKI. - This new IRR would accept 'route' objects generated from the global RPKI, and would therefore cover the entire routing space, in so much as the RPKI covers the global space. - Operators who use the IRR to generate routing filters can choose to put this new IRR registry logically in front of the other registries. Operators can then give preference to routing origin information that can be formally validated, and eventually, can would be able to filter explicitly based on this information. - This new registry would be made available as an IRR publication point. 4.2 ARIN publish an open source tool that enables network operators to generate their own overlay IRR publication points themselves. - Such generated IRR publication points should be identical to the one generated and made available today by ARIN. - Producing overlay IRR publication points allows security conscious operators to have a more formal trust model that prevents attacks on the IRR segment generated and served by ARIN. 5. Advantages and disadvantages of the proposal ------------------------------------------------- Advantages: - Router filters would be more reliable as they would prefer RPKI validated origins, where available, rather than those not validated in the RPKI. ISPs would achieve this by configuring tools that automatically generate router filters to give priority to the IRR publication point of the new registry based on RPKI-signed objects. - The community will have an enhanced ability to filter BGP peer prefixes at no additional cost or changes to the data or tool bases. This would increase the reliability and security of the global routing system. - This new IRR publication point would be much simpler than other current ideas about how to use RPKI in conjunction with IRR data. - This proposal requires no changes to RPSL, the IRR, IRR toolsets, or the RPKI. Disadvantages: - None are known 6. Effect on ARIN members ---------------------------- See 'Advantages' above. 7. Effect on NIRs ----------------- None are known 8. Timeline to Implementation ----------------------------- ASAP. From randy at psg.com Wed May 7 10:04:42 2008 From: randy at psg.com (Randy Bush) Date: Wed, 07 May 2008 16:04:42 +0200 Subject: [arin-ppml] Using RPKI to Construct Validated IRR Data In-Reply-To: <41F80CE2-8600-4E76-B91E-1B0C7D41A815@tcb.net> References: <41F80CE2-8600-4E76-B91E-1B0C7D41A815@tcb.net> Message-ID: <4821B6FA.7050103@psg.com> Danny McPherson wrote: > Also, note that Kurtis presented a near identical > proposal at RIPE earlier this week, with Randy as the anchor > author, and the slides are available here: > > in apnic, it is proposal prop-059, randy From dudepron at gmail.com Wed May 7 10:16:57 2008 From: dudepron at gmail.com (Aaron) Date: Wed, 7 May 2008 10:16:57 -0400 Subject: [arin-ppml] Using RPKI to Construct Validated IRR Data In-Reply-To: <4821B6FA.7050103@psg.com> References: <41F80CE2-8600-4E76-B91E-1B0C7D41A815@tcb.net> <4821B6FA.7050103@psg.com> Message-ID: <480dad640805070716g46a62edcje7572f8bbaf615f6@mail.gmail.com> What about providers who currently do not use the IRR? Does this force them to do the minimal work like getting their allocation in? Aaron On Wed, May 7, 2008 at 10:04 AM, Randy Bush wrote: > Danny McPherson wrote: > > Also, note that Kurtis presented a near identical > > proposal at RIPE earlier this week, with Randy as the anchor > > author, and the slides are available here: > > > > > > in apnic, it is proposal prop-059, > > > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed May 7 10:26:34 2008 From: randy at psg.com (Randy Bush) Date: Wed, 07 May 2008 16:26:34 +0200 Subject: [arin-ppml] Using RPKI to Construct Validated IRR Data In-Reply-To: <480dad640805070716g46a62edcje7572f8bbaf615f6@mail.gmail.com> References: <41F80CE2-8600-4E76-B91E-1B0C7D41A815@tcb.net> <4821B6FA.7050103@psg.com> <480dad640805070716g46a62edcje7572f8bbaf615f6@mail.gmail.com> Message-ID: <4821BC1A.3030605@psg.com> Aaron wrote: > What about providers who currently do not use the IRR? Does this force them > to do the minimal work like getting their allocation in? no From danny at tcb.net Wed May 7 10:28:59 2008 From: danny at tcb.net (Danny McPherson) Date: Wed, 7 May 2008 08:28:59 -0600 Subject: [arin-ppml] Using RPKI to Construct Validated IRR Data In-Reply-To: <480dad640805070716g46a62edcje7572f8bbaf615f6@mail.gmail.com> References: <41F80CE2-8600-4E76-B91E-1B0C7D41A815@tcb.net> <4821B6FA.7050103@psg.com> <480dad640805070716g46a62edcje7572f8bbaf615f6@mail.gmail.com> Message-ID: On May 7, 2008, at 8:16 AM, Aaron wrote: > What about providers who currently do not use the IRR? Does this > force them to do the minimal work like getting their allocation in? Nope, it will be populated by the RIRs generated from the RPKI. It should encourage them to start using the IRRs, but there's no requirement there. -danny From info at arin.net Wed May 7 11:27:06 2008 From: info at arin.net (Member Services) Date: Wed, 07 May 2008 11:27:06 -0400 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request Message-ID: <4821CA4A.1040806@arin.net> Your comments are requested on the proposed policy development process! Please post your opinions to arin-ppml at arin.net no later than 5 PM EDT, Friday, 9 May 2008. On 8 April 2008, at ARIN XXI in Denver, Colorado, Scott Bradner presented a proposed policy development process (PDP) to replace the current Internet Resource Policy Evaluation Process (IRPEP). The proposed PDP is intended to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments before discussion; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption. The proposed PDP empowers the ARIN Advisory Council by shifting its scope from a policy advisory body to a policy development body while providing checks and balances and maintains an open and transparent process. The presentation can be found at: http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html and the webcast can be found at: http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html. The full text for the proposed PDP can be found in the attached PDF or in text below. Regards, Member Services American Registry for Internet Numbers (ARIN) ****************************************************** PRINCIPLE ARIN's Internet Resource Policies are documented community decisions that directly determine the rules by which Internet numbering resources are managed and administered by ARIN. Internet Resource Policies are developed in an open and transparent manner by the Internet community. Anyone may participate in the process - ARIN membership is not required. The Policy Development Process (PDP) described in this document defines how policy is established in the ARIN region. The ARIN Board of Trustees adopts proposed Internet Number Resource Policies recommended to it by the ARIN Advisory Council (AC) if the Board determines that the PDP has been followed, that support and consensus for a policy has been reached among the community, and if the proposed policies are consistent with ARIN's Articles of Incorporation and Bylaws and with the applicable laws and regulations. It is important to note that Internet Resource Policies are distinctly separate from ARIN general business practices and procedures. ARIN's general business practices (including fees) and procedures are not within the purview of the Policy Development Process. (The ARIN Consultation and Suggestion Process can be used to propose changes in non-policy areas.) OVERIVEW The proposed PDP is intended to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments before discussion; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption. The proposed PDP empowers the ARIN Advisory Council by shifting its scope from a policy advisory body to a policy development body while providing checks and balances and maintains an open and transparent process. THE POLICY DEVEOPMENT PROCESS 1. Proposal. [15 Days, maximum] a. Submittal. Policy proposals may be submitted at any time. Anyone in the community, except a member of the ARIN Board of Trustees or a member of ARIN staff can originate a policy proposal. Policy proposals must be sent to the policy e-mail address at ARIN. Proposals can be submitted at any time but only proposals received more than 70 days before a Public Policy Meeting (PPM) can generate a draft policy for consideration at that meeting. b. Clarity & Understanding. ARIN staff works with the proposal originator to ensure there is clarity and understanding of what is being proposed. The staff does not evaluate the proposal itself at this stage, their only aim is to make sure that they understand what the proposal is proposing and believe that the community will as well. If understanding is reached the proposal is announced to the community via the ARIN Public Policy Mailing List (PPML) and forwarded to the AC. The proposal is dropped if the staff and originator cannot reach an agreement on clear and understandable text. In this case, the originator may make a Submittal Petition and send the proposal to PPML and request community support to have the proposal forwarded to the AC for review. There is no AC action in this phase. 2. Draft Policy. [30 Days, maximum] a. Development & Evaluation. The AC assumes ownership of all proposals. The AC develops and evaluates proposals to only bring forth technically sound policies that make a positive contribution to the Number Resource Policy Manual. The AC may rewrite, merge, abandon, etc.; for example, they may use a proposal as an idea to generate a draft policy. If the AC intends to move a draft policy forward, it must first submit it for staff and legal review (10 days max to perform). The AC must understand and address staff and legal comments before a proposal may go on. These comments may cause the AC to revise a draft policy. b. Selection. The AC selects the draft policies that will be published for discussion and review by the community on the PPML. The relevant staff and legal comments will be published along with each draft policy. If any member of the community, including a proposal originator, is dissatisfied with the AC action on a policy proposal they can initiate a Discussion Petition to move this particular proposal to the PPML for discussion as a draft policy. A successful petition may result in competing versions of the same draft policy. Staff and legal review will be conducted and published for successful petitions. 3. Discussion and Review. [25 Days, minimum] Only draft policies selected by the AC or successfully petitioned are open to community discussion and review on PPML. The text of all draft policies is frozen at 10 days prior to the Public Policy Meeting. The text remains frozen until after the completion of the Public Policy Meeting so that a single text for each draft policy is considered at the meeting. 4. Public Policy Meeting. The AC presents draft policies at the Public Policy Meeting; the successful petitioner presents theirs. Competing proposals, if any, will be discussed together. Discussion and votes at the meeting are for the consideration of the AC. 5. Consensus. a. Discussion Evaluation. [30 Days, maximum] At the conclusion of the PPM the AC owns all draft policies, including those that were successfully petitioned. The AC reviews all draft policies and, taking into account discussion both on the PPML and at the Public Policy Meeting, decides what to do with each draft policy. The AC may rewrite, merge, abandon, send to last call, etc. The results of the AC's decisions are announced to the PPML. Draft policies that are not abandoned or sent to last call are placed on the AC docket for further development and evaluation. If any member of the community, including a proposal originator, is dissatisfied with the AC action on a policy proposal they can initiate a Last Call Petition to move this particular proposal to the PPML for last call. b. Last Call [10 Days, minimum] The AC selects draft policies that have support both in the community and the AC itself and sends them to a last call for comments on the PPML. The last call period will be for a minimum of 10 days. The AC may decide that certain draft proposals may require a longer last call period of review, such as those that were revised based on comments received while the text was frozen. If the AC sends a draft policy to last call that is different from the frozen version, then the AC will explain and justify changes to the text. c. Last Call Review [30 Days, maximum] The AC determines consensus for each draft policy by reviewing last call comments, revisiting its decision (the AC may rewrite, merge, abandon, etc.), and determining readiness for consideration by the Board of Trustees. If the AC modifies a draft policy, it will be sent for another round of last call or may be placed back on the AC's docket for further development and evaluation. If any member of the community is dissatisfied with the AC action on a policy proposal they can initiate a Board of Trustees Consideration Petition to move this particular proposal for consideration by the Board of Trustees. The results of the AC's decisions are announced to the PPML. The AC forwards the draft policies that it supports to the Board of Trustees for consideration. 6. Board of Trustee Review. [30 Days, maximum] The ARIN Board of Trustees reviews and evaluates each draft policy presented to it. The Board examines each draft policy in terms of fiduciary risk, liability risk, conformity to law, development in accordance with the ARIN PDP, and adherence to the ARIN Articles of Incorporation and bylaws. The Board may adopt, reject or remand draft policies to the AC. Rejections will include an explanation. Remands will include an explanation and a recommendation. The Board may also seek clarification from the AC without remanding the draft policy. The results of the Board's decision are announced to the community via PPML. 7. Implementation. The expected implementation date of the policy is announced at the time that adoption of the policy is announced. ARIN staff updates to include the adopted policy into the Number Resource Policy Manual and implements and publishes a new version of the manual. From danny at tcb.net Wed May 7 13:27:51 2008 From: danny at tcb.net (Danny McPherson) Date: Wed, 7 May 2008 11:27:51 -0600 Subject: [arin-ppml] Using RPKI to Construct Validated IRR Data In-Reply-To: References: <41F80CE2-8600-4E76-B91E-1B0C7D41A815@tcb.net> <4821B6FA.7050103@psg.com> <480dad640805070716g46a62edcje7572f8bbaf615f6@mail.gmail.com> Message-ID: On May 7, 2008, at 8:28 AM, Danny McPherson wrote: > > On May 7, 2008, at 8:16 AM, Aaron wrote: > >> What about providers who currently do not use the IRR? Does this >> force them to do the minimal work like getting their allocation in? > > Nope, it will be populated by the RIRs generated from > the RPKI. It should encourage them to start using the > IRRs, but there's no requirement there. A quick write-up on some of this, for folks interested: HTH, -danny From JOHN at egh.com Wed May 7 15:21:38 2008 From: JOHN at egh.com (John Santos) Date: Wed, 7 May 2008 15:21:38 -0400 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: <4821CA4A.1040806@arin.net> Message-ID: <1080507145300.358C-100000@Ives.egh.com> I have two problems with this proposal. 1) At several places, disatisfied originators can initiate petitions to bypass AC decisions. The proposal then describes what happens to "successful petitions". What makes a petition successful? Does it just need to be entered or does it need to be seconded or supported by some minimum number of "petition signers?" Who makes the decision on whether a petition is "successful" or not? 2) At various points (2a, 5a) in the process, the policy proposal is describe as becoming "owned" by the AC. Does this mean that the proposal is "property?" Given the current discussions of whether various actions and activities imply that IP addresses are property, maybe we should steer clear of that verb, substituting something like "the AC is responible for the proposal" for "the AC owns the proposal." Worst case scenario: The A/C slightly changes the wording of a policy at the draft stage in a way that the originator feels completely undermines the intent of the proposal (changes a "shall" to a "may", for example.) The originator petitions to have the draft reconsidered with his original wording. The A/C sues the originator for copyright infringement because it "owns" the proposal. :-) :-) (I know that "owns" is commonly used in business jargon to describe a project, policy, process, etc. being under the purview of a particular person or organization, but in my dictionary (Webster's New World Dictionary, 2nd College Edition, 1968), "own" is quite narrowly defined as "to posses; hold as personal property; have", and "ownership" is defined as "legal right of possession; lawful title (to something); proprietorship") -- John On Wed, 7 May 2008, Member Services wrote: > Your comments are requested on the proposed policy development process! > Please post your opinions to arin-ppml at arin.net no later than 5 PM EDT, > Friday, 9 May 2008. > > On 8 April 2008, at ARIN XXI in Denver, Colorado, Scott Bradner > presented a proposed policy development process (PDP) to replace the > current Internet Resource Policy Evaluation Process (IRPEP). The > proposed PDP is intended to bring forth clear, technically sound and > useful policy; reduce overlapping policy proposals; require both staff > and legal assessments before discussion; give adequate opportunity for > discussion prior to each public policy meeting; and provide a means of > review prior to possible adoption. The proposed PDP empowers the ARIN > Advisory Council by shifting its scope from a policy advisory body to a > policy development body while providing checks and balances and > maintains an open and transparent process. > > The presentation can be found at: > http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html > > and the webcast can be found at: > http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html. > > The full text for the proposed PDP can be found in the attached PDF or > in text below. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > ****************************************************** > > PRINCIPLE > > ARIN's Internet Resource Policies are documented community decisions > that directly determine the rules by which Internet numbering resources > are managed and administered by ARIN. Internet Resource Policies are > developed in an open and transparent manner by the Internet community. > > Anyone may participate in the process - ARIN membership is not required. > > The Policy Development Process (PDP) described in this document defines > how policy is established in the ARIN region. > > The ARIN Board of Trustees adopts proposed Internet Number Resource > Policies recommended to it by the ARIN Advisory Council (AC) if the > Board determines that the PDP has been followed, that support and > consensus for a policy has been reached among the community, and if the > proposed policies are consistent with ARIN's Articles of Incorporation > and Bylaws and with the applicable laws and regulations. > > It is important to note that Internet Resource Policies are distinctly > separate from ARIN general business practices and procedures. ARIN's > general business practices (including fees) and procedures are not > within the purview of the Policy Development Process. (The ARIN > Consultation and Suggestion Process can be used to propose changes in > non-policy areas.) > > OVERIVEW > > The proposed PDP is intended to bring forth clear, technically sound and > useful policy; reduce overlapping policy proposals; require both staff > and legal assessments before discussion; give adequate opportunity for > discussion prior to each public policy meeting; and provide a means of > review prior to possible adoption. The proposed PDP empowers the ARIN > Advisory Council by shifting its scope from a policy advisory body to a > policy development body while providing checks and balances and > maintains an open and transparent process. > > THE POLICY DEVEOPMENT PROCESS > > 1. Proposal. [15 Days, maximum] > > a. Submittal. Policy proposals may be submitted at any time. > Anyone in the community, except a member of the ARIN Board of Trustees > or a member of ARIN staff can originate a policy proposal. Policy > proposals must be sent to the policy e-mail address at ARIN. Proposals > can be submitted at any time but only proposals received more than 70 > days before a Public Policy Meeting (PPM) can generate a draft policy > for consideration at that meeting. > > b. Clarity & Understanding. ARIN staff works with the proposal > originator to ensure there is clarity and understanding of what is being > proposed. The staff does not evaluate the proposal itself at this stage, > their only aim is to make sure that they understand what the proposal is > proposing and believe that the community will as well. > > If understanding is reached the proposal is announced to the community > via the ARIN Public Policy Mailing List (PPML) and forwarded to the AC. > The proposal is dropped if the staff and originator cannot reach an > agreement on clear and understandable text. > > In this case, the originator may make a Submittal Petition and send the > proposal to PPML and request community support to have the proposal > forwarded to the AC for review. There is no AC action in this phase. > > > 2. Draft Policy. [30 Days, maximum] > > a. Development & Evaluation. The AC assumes ownership of all > proposals. The AC develops and evaluates proposals to only bring forth > technically sound policies that make a positive contribution to the > Number Resource Policy Manual. The AC may rewrite, merge, abandon, etc.; > for example, they may use a proposal as an idea to generate a draft policy. > > If the AC intends to move a draft policy forward, it must first submit > it for staff and legal review (10 days max to perform). The AC must > understand and address staff and legal comments before a proposal may go > on. These comments may cause the AC to revise a draft policy. > > b. Selection. The AC selects the draft policies that will be > published for discussion and review by the community on the PPML. The > relevant staff and legal comments will be published along with each > draft policy. > > If any member of the community, including a proposal originator, is > dissatisfied with the AC action on a policy proposal they can initiate a > Discussion Petition to move this particular proposal to the PPML for > discussion as a draft policy. > > A successful petition may result in competing versions of the same draft > policy. Staff and legal review will be conducted and published for > successful petitions. > > > 3. Discussion and Review. [25 Days, minimum] > > Only draft policies selected by the AC or successfully petitioned are > open to community discussion and review on PPML. The text of all draft > policies is frozen at 10 days prior to the Public Policy Meeting. The > text remains frozen until after the completion of the Public Policy > Meeting so that a single text for each draft policy is considered at the > meeting. > > > 4. Public Policy Meeting. The AC presents draft policies at the Public > Policy Meeting; the successful petitioner presents theirs. Competing > proposals, if any, will be discussed together. Discussion and votes at > the meeting are for the consideration of the AC. > > > 5. Consensus. > > a. Discussion Evaluation. [30 Days, maximum] At the conclusion > of the PPM the AC owns all draft policies, including those that were > successfully petitioned. The AC reviews all draft policies and, taking > into account discussion both on the PPML and at the Public Policy > Meeting, decides what to do with each draft policy. The AC may rewrite, > merge, abandon, send to last call, etc. The results of the AC's > decisions are announced to the PPML. Draft policies that are not > abandoned or sent to last call are placed on the AC docket for further > development and evaluation. > > If any member of the community, including a proposal originator, is > dissatisfied with the AC action on a policy proposal they can initiate a > Last Call Petition to move this particular proposal to the PPML for last > call. > > b. Last Call [10 Days, minimum] The AC selects draft policies > that have support both in the community and the AC itself and sends them > to a last call for comments on the PPML. > > The last call period will be for a minimum of 10 days. The AC may decide > that certain draft proposals may require a longer last call period of > review, such as those that were revised based on comments received while > the text was frozen. If the AC sends a draft policy to last call that is > different from the frozen version, then the AC will explain and justify > changes to the text. > > c. Last Call Review [30 Days, maximum] The AC determines > consensus for each draft policy by reviewing last call comments, > revisiting its decision (the AC may rewrite, merge, abandon, etc.), and > determining readiness for consideration by the Board of Trustees. If the > AC modifies a draft policy, it will be sent for another round of last > call or may be placed back on the AC's docket for further development > and evaluation. > > If any member of the community is dissatisfied with the AC action on a > policy proposal they can initiate a Board of Trustees Consideration > Petition to move this particular proposal for consideration by the Board > of Trustees. > > The results of the AC's decisions are announced to the PPML. The AC > forwards the draft policies that it supports to the Board of Trustees > for consideration. > > 6. Board of Trustee Review. [30 Days, maximum] The ARIN Board of > Trustees reviews and evaluates each draft policy presented to it. The > Board examines each draft policy in terms of fiduciary risk, liability > risk, conformity to law, development in accordance with the ARIN PDP, > and adherence to the ARIN Articles of Incorporation and bylaws. The > Board may adopt, reject or remand draft policies to the AC. Rejections > will include an explanation. Remands will include an explanation and a > recommendation. The Board may also seek clarification from the AC > without remanding the draft policy. The results of the Board's decision > are announced to the community via PPML. > > 7. Implementation. The expected implementation date of the policy is > announced at the time that adoption of the policy is announced. ARIN > staff updates to include the adopted policy into the Number Resource > Policy Manual and implements and publishes a new version of the manual. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From bill at herrin.us Wed May 7 16:43:08 2008 From: bill at herrin.us (William Herrin) Date: Wed, 7 May 2008 16:43:08 -0400 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: <4821CA4A.1040806@arin.net> References: <4821CA4A.1040806@arin.net> Message-ID: <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> On Wed, May 7, 2008 at 11:27 AM, Member Services wrote: > Your comments are requested on the proposed policy development process! > Please post your opinions to arin-ppml at arin.net no later than 5 PM EDT, > Friday, 9 May 2008. At a glance, it looks like this proposal alters the AC's role from being knowledge resources to being traffic cops. Everybody hates traffic cops. Right now, the policy development process starts with an idea, a complaint, a hypothetical that comes as often as not from someone who has little or no experience with ARIN. The notion finds its way to PPML in one form or another where it gets informally bounced back and forth and eventually coalesces into a proposal. This is a very healthy, very bottom-up process. It contributes heavily to ARIN's relative reputation for trustworthiness (as opposed to say, ICANN), even though ARIN is placed in the unfortunate position of blocking and rejecting IP address requests from organizations too small to play (which is almost everybody). This proposed change cuts or at best ignores that vital first step in the policy development process. The proposed process -starts- with the formal proposal. Do you propose to change the mailing list so that discussion starts with a proposal that has passed the AC's first review? Police it to assure that participants stay on topic? Limit it so that only folks who have achieved enough expertise in ARINology can initiate a discussion (by way of a proposal)? It would be nice to avoid overlapping and confusing proposals, policy text in flux even at the meetings and staff comments about the technical soundness of a proposal that arrive too late to discuss changes before the meeting. However, in my ever so humble opinion, we have a Really Good Process in place already and not one of those goals (or all of them together) is worth the RISK of damaging that process that a significant overhaul represents. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sleibrand at internap.com Wed May 7 16:58:40 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 07 May 2008 13:58:40 -0700 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> References: <4821CA4A.1040806@arin.net> <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> Message-ID: <48221800.80904@internap.com> Bill, I don't think the proposed changes would change the informal pre-proposal activities at all. There are no proposals I know of to limit pre-proposal discussion on PPML in any way, and we still think that such discussion is good and valuable, and should usually occur in advance of any formal process. I also asked Scott Bradner the same question a while back, and he confirmed that PPML would remain open. It's just what happens after a proposal is formally submitted to policy at arin.net that would be changing under the proposed new PDP. Does that address your concerns? -Scott William Herrin wrote: > On Wed, May 7, 2008 at 11:27 AM, Member Services wrote: >> Your comments are requested on the proposed policy development process! >> Please post your opinions to arin-ppml at arin.net no later than 5 PM EDT, >> Friday, 9 May 2008. > > At a glance, it looks like this proposal alters the AC's role from > being knowledge resources to being traffic cops. Everybody hates > traffic cops. > > Right now, the policy development process starts with an idea, a > complaint, a hypothetical that comes as often as not from someone who > has little or no experience with ARIN. The notion finds its way to > PPML in one form or another where it gets informally bounced back and > forth and eventually coalesces into a proposal. > > This is a very healthy, very bottom-up process. It contributes heavily > to ARIN's relative reputation for trustworthiness (as opposed to say, > ICANN), even though ARIN is placed in the unfortunate position of > blocking and rejecting IP address requests from organizations too > small to play (which is almost everybody). > > This proposed change cuts or at best ignores that vital first step in > the policy development process. The proposed process -starts- with the > formal proposal. Do you propose to change the mailing list so that > discussion starts with a proposal that has passed the AC's first > review? Police it to assure that participants stay on topic? Limit it > so that only folks who have achieved enough expertise in ARINology can > initiate a discussion (by way of a proposal)? > > > It would be nice to avoid overlapping and confusing proposals, policy > text in flux even at the meetings and staff comments about the > technical soundness of a proposal that arrive too late to discuss > changes before the meeting. However, in my ever so humble opinion, we > have a Really Good Process in place already and not one of those goals > (or all of them together) is worth the RISK of damaging that process > that a significant overhaul represents. > > Regards, > Bill Herrin > > From bill at herrin.us Wed May 7 17:08:09 2008 From: bill at herrin.us (William Herrin) Date: Wed, 7 May 2008 17:08:09 -0400 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: <48221800.80904@internap.com> References: <4821CA4A.1040806@arin.net> <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> <48221800.80904@internap.com> Message-ID: <3c3e3fca0805071408m1249ec66wde52ed1ba96738cc@mail.gmail.com> On Wed, May 7, 2008 at 4:58 PM, Scott Leibrand wrote: > Bill, > > I don't think the proposed changes would change the informal pre-proposal > activities at all. There are no proposals I know of to limit pre-proposal > discussion on PPML in any way, and we still think that such discussion is > good and valuable, and should usually occur in advance of any formal > process. I also asked Scott Bradner the same question a while back, and he > confirmed that PPML would remain open. > > It's just what happens after a proposal is formally submitted to > policy at arin.net that would be changing under the proposed new PDP. > > Does that address your concerns? Scott, I'd be a lot happier if that was written explicitly into the proposed process. When I see phrases like "require both staff and legal assessments BEFORE discussion" in the overview it fires off all sorts of red flags. I'm not opposed to some mild structure tweaks towards then end of the process when we're trying to zero in on a single, formal policy that's ready for formal discussion at the meeting followed by adoption but the front of the process is awfully good already, good enough that changes are likely to make it worse. Regards, Bill -- 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 Wed May 7 17:45:01 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 7 May 2008 14:45:01 -0700 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: <1080507145300.358C-100000@Ives.egh.com> References: <1080507145300.358C-100000@Ives.egh.com> Message-ID: On May 7, 2008, at 12:21 PM, John Santos wrote: > > I have two problems with this proposal. 1) At several places, > disatisfied > originators can initiate petitions to bypass AC decisions. The > proposal > then describes what happens to "successful petitions". What makes a > petition successful? Does it just need to be entered or does it need > to be seconded or supported by some minimum number of "petition > signers?" > Who makes the decision on whether a petition is "successful" or not? > John, I completely agree with you here and have asked for clarification in this area. > 2) At various points (2a, 5a) in the process, the policy proposal > is describe as becoming "owned" by the AC. Does this mean that the > proposal is "property?" Given the current discussions of whether > various actions and activities imply that IP addresses are property, > maybe we should steer clear of that verb, substituting something like > "the AC is responible for the proposal" for "the AC owns the > proposal." > Agreed that some word smithing could improve things with this. In case there's any lack of clarity, my understanding of the intended purpose is that the AC, upon acceptance of the proposal is given the ability to modify, alter, merge, etc. the proposal which is currently restricted to the proposal authors. The petition capability is intended as a safety valve against the AC arbitrarily altering the author's intent in a way contrary to the desire of the community. I think this will actually improve the process, and, assuming that the petition safety valve is at a sufficiently low threshold, I am confident it will not reduce community involvement in the process or prevent authors from expressing their true intent. Owen From dean at av8.net Wed May 7 23:16:36 2008 From: dean at av8.net (Dean Anderson) Date: Wed, 7 May 2008 23:16:36 -0400 (EDT) Subject: [arin-ppml] Legacy Space authority (fwd) In-Reply-To: <014f01c8aedb$210e1120$6fce4b41@tedsdesk> Message-ID: On Mon, 5 May 2008, Ted Mittelstaedt wrote: > I note in the 100% of these that YOU respond to by claiming your > going to set your lawyer on suing any of these organizations and > people, YOU never actually do so, either. Your assertion is false. I've never made such a threat on a mailing list. I merely quote the law. If people disregard the law, they may or may not suffer consequences. If they do suffer consequences, those consequences may or may not come from my lawyer. But I will say that there are usually consequences of /some/ sort for disregarding the law; for making false fictional statements; for associating with disreputable people who make false fictional statements, who threaten violence, etc. Indeed, I think there are almost always consequences for dishonesty and reprehensible uncivil behavior. Its just a matter of time... Honest people are, well, /honest/ and don't do those things or associate with those kind of people. Government and industry, /society/, wants honest people of character and integrity. There are no merit badges for deceptive statements, disregard for the law or for undisclosed conflict of interest. > > I've been keeping track. > > Must...restrain...myself...from...making...smartass...comment.... > very....difficult..... Well, I /have been/ keeping track. I'll let you know when I publish web pages on the activities of Vixie, Plzak, Curran, Bradner, etc, if you like. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From michael.dillon at bt.com Thu May 8 03:42:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 8 May 2008 08:42:51 +0100 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> References: <4821CA4A.1040806@arin.net> <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> Message-ID: > Right now, the policy development process starts with an > idea, a complaint, a hypothetical that comes as often as not > from someone who has little or no experience with ARIN. The > notion finds its way to PPML in one form or another where it > gets informally bounced back and forth and eventually > coalesces into a proposal. > > This is a very healthy, very bottom-up process. It > contributes heavily to ARIN's relative reputation for > trustworthiness (as opposed to say, ICANN), even though ARIN > is placed in the unfortunate position of blocking and > rejecting IP address requests from organizations too small to > play (which is almost everybody). > > This proposed change cuts or at best ignores that vital first > step in the policy development process. The proposed process > -starts- with the formal proposal. I tend to agree with this critique. In general, the new PDP is OK, but I think it is unfair at the very beginning. It should still be possible for people to write and submit proposals just as they do today. However, unlike today, these proposals are not guaranteed to progress through the PDP. They can be discussed on the PPML and by the AC, and eventually, the AC may decide to create a formal proposal based on the submitted proposal(s) and the discussion. This solves the problem of overlapping proposals because they don't ever go through the formal process. The AC has the power to combine all the overlapping proposals and other input to create a formal proposal. Or they can ignore all of them if they wish. --Michael Dillon From owen at delong.com Thu May 8 05:52:09 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 8 May 2008 02:52:09 -0700 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: References: <4821CA4A.1040806@arin.net> <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> Message-ID: On May 8, 2008, at 12:42 AM, wrote: > >> Right now, the policy development process starts with an >> idea, a complaint, a hypothetical that comes as often as not >> from someone who has little or no experience with ARIN. The >> notion finds its way to PPML in one form or another where it >> gets informally bounced back and forth and eventually >> coalesces into a proposal. >> >> This is a very healthy, very bottom-up process. It >> contributes heavily to ARIN's relative reputation for >> trustworthiness (as opposed to say, ICANN), even though ARIN >> is placed in the unfortunate position of blocking and >> rejecting IP address requests from organizations too small to >> play (which is almost everybody). >> >> This proposed change cuts or at best ignores that vital first >> step in the policy development process. The proposed process >> -starts- with the formal proposal. > > I tend to agree with this critique. In general, the new PDP is > OK, but I think it is unfair at the very beginning. It should > still be possible for people to write and submit proposals > just as they do today. However, unlike today, these proposals > are not guaranteed to progress through the PDP. They can be > discussed on the PPML and by the AC, and eventually, the AC > may decide to create a formal proposal based on the submitted > proposal(s) and the discussion. > I think you need to re-examine the current IRPEP. There's very little modification to the initial part other than adding interaction with ARIN staff and an earlier legal review to assist the author in crafting a policy which can actually be implemented and really meets the author's intent. The proposed PDP does not prevent people from writing and submitting proposals just as they do today. The current IRPEP does not guarantee that proposals move through the process. See the IRPEP under the heading "Initial Review" and you will notice that at that early point, the AC does have the option of abandoning policies. There is a petition process in this case. The proposed PDP provides pretty much the same options. > This solves the problem of overlapping proposals because they > don't ever go through the formal process. The AC has the power > to combine all the overlapping proposals and other input to > create a formal proposal. Or they can ignore all of them if > they wish. > Yes.. The ability to edit, combine, etc. is the major change in the new proposal. The ability to abandon a proposal is not new. The ability to discuss potential proposals informally on PPML does not go away with the new process. The petition process details still need to be defined, but, assuming a similarly low threshold for petition success in the new proposed process, I don't see a significant difference in the bottom-up nature. Owen From plzak at arin.net Thu May 8 06:06:09 2008 From: plzak at arin.net (Ray Plzak) Date: Thu, 8 May 2008 06:06:09 -0400 Subject: [arin-ppml] REMINDER: Proposed PDP Community Review Request In-Reply-To: References: <4821CA4A.1040806@arin.net> <3c3e3fca0805071343l4313ac82m213bad81e734065f@mail.gmail.com> Message-ID: Owen, Later this morning ARIN will post to the ppml the petition process in the revised PDP. It now has 4 petition points instead of the current 2. The thresholds and procedure are in consonance with the current petition process. Ray > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, May 08, 2008 5:52 AM > To: michael.dillon at bt.com > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] REMINDER: Proposed PDP Community Review > Request > > > On May 8, 2008, at 12:42 AM, wrote: > > > > >> Right now, the policy development process starts with an > >> idea, a complaint, a hypothetical that comes as often as not > >> from someone who has little or no experience with ARIN. The > >> notion finds its way to PPML in one form or another where it > >> gets informally bounced back and forth and eventually > >> coalesces into a proposal. > >> > >> This is a very healthy, very bottom-up process. It > >> contributes heavily to ARIN's relative reputation for > >> trustworthiness (as opposed to say, ICANN), even though ARIN > >> is placed in the unfortunate position of blocking and > >> rejecting IP address requests from organizations too small to > >> play (which is almost everybody). > >> > >> This proposed change cuts or at best ignores that vital first > >> step in the policy development process. The proposed process > >> -starts- with the formal proposal. > > > > I tend to agree with this critique. In general, the new PDP is > > OK, but I think it is unfair at the very beginning. It should > > still be possible for people to write and submit proposals > > just as they do today. However, unlike today, these proposals > > are not guaranteed to progress through the PDP. They can be > > discussed on the PPML and by the AC, and eventually, the AC > > may decide to create a formal proposal based on the submitted > > proposal(s) and the discussion. > > > I think you need to re-examine the current IRPEP. There's very > little modification to the initial part other than adding interaction > with ARIN staff and an earlier legal review to assist the author > in crafting a policy which can actually be implemented and really > meets the author's intent. > > The proposed PDP does not prevent people from writing and > submitting proposals just as they do today. The current IRPEP > does not guarantee that proposals move through the process. > > See the IRPEP under the heading "Initial Review" and you > will notice that at that early point, the AC does have the option > of abandoning policies. There is a petition process in this case. > The proposed PDP provides pretty much the same options. > > > > This solves the problem of overlapping proposals because they > > don't ever go through the formal process. The AC has the power > > to combine all the overlapping proposals and other input to > > create a formal proposal. Or they can ignore all of them if > > they wish. > > > Yes.. The ability to edit, combine, etc. is the major change in > the new proposal. > > The ability to abandon a proposal is not new. The ability to > discuss potential proposals informally on PPML does not go > away with the new process. > > The petition process details still need to be defined, but, assuming > a similarly low threshold for petition success in the new proposed > process, I don't see a significant difference in the bottom-up > nature. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if > you experience any issues. From info at arin.net Thu May 8 08:12:44 2008 From: info at arin.net (Member Services) Date: Thu, 08 May 2008 08:12:44 -0400 Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9 May Message-ID: <4822EE3C.1000800@arin.net> Recent comments on the PPML have requested more detail regarding the petition process. The proposed Policy Development Process (PDP) increases the number of petition points from two (2) to four (4). The threshold levels and process activity for these petitions are in consonance with the existing petition process. The details of the petition process are provided in the text below. REMINDER: Please post your opinions to arin-ppml at arin.net no later than 5 PM EDT, Friday, 9 May 2008. Regards, Member Services American Registry for Internet Numbers (ARIN) ****************************************************** OVERVIEW The proposed PDP is intended to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments before discussion; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption. The proposed PDP empowers the ARIN Advisory Council by shifting its scope from a policy advisory body to a policy development body while providing checks and balances and maintains an open and transparent process. The checks and balances are provided through the means to petition at various points in the PDP. THE PETITION PROCESS At each point in the process where a decision is made there is a means for this decision to be overruled. 1. Submittal Petition. [10 days, maximum] If the staff and originator cannot reach an agreement on clear and understandable text, the originator may make a Submittal Petition and send the proposal to PPML and request community support to have the proposal forwarded to the AC for review. The originator is responsible for initiating the petition on the PPML (within 5 business days of a good faith effort to reach agreement or after the end of the process time limit for this step); the message must include the proposal and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 5 different people from 5 different organizations. 2. Discussion Petition. [10 days, maximum] If any member of the community, including a proposal originator, is dissatisfied with the AC action on a policy proposal they can initiate a Discussion Petition to move this particular proposal to the PPML for discussion as a draft policy. Anyone may initiate the petition on the PPML (within 5 business days of publication of the AC's decision or after the end of the process time limit for this step); the petition must include the proposal and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 10 different people from 10 different organizations. 3. Last Call Petition. [10 days, maximum] If any member of the community, including a proposal originator, is dissatisfied with the AC action on a draft policy they can initiate a Last Call Petition to move this particular draft policy to the PPML for last call. Anyone may initiate the petition on the PPML (within 5 business days of the publication of the AC's decision or after the end of the process time limit for this step); the petition must include the draft policy and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 10 different people from 10 different organizations. 4. Board of Trustees Consideration Petition. [10 days, maximum] If any member of the community is dissatisfied with the AC action on a draft policy they can initiate a Board of Trustees Consideration Petition to move this particular draft policy for consideration by the Board of Trustees. Anyone may initiate the petition on the PPML (within 5 business days of the publication of the AC's decision or after the end of the process time limit for this step); the petition must include the draft policy and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 10 different people from 10 different organizations. ********************************************* From owen at delong.com Thu May 8 11:39:48 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 8 May 2008 08:39:48 -0700 Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9 May In-Reply-To: <4822EE3C.1000800@arin.net> References: <4822EE3C.1000800@arin.net> Message-ID: <7D8CF6AE-B21B-4EDF-B6B6-363FF7CEA954@delong.com> > > OVERVIEW > > The proposed PDP is intended to bring forth clear, technically sound > and > useful policy; reduce overlapping policy proposals; require both staff > and legal assessments before discussion; give adequate opportunity for > discussion prior to each public policy meeting; and provide a means of > review prior to possible adoption. The proposed PDP empowers the ARIN > Advisory Council by shifting its scope from a policy advisory body > to a > policy development body while providing checks and balances and > maintains an open and transparent process. The checks and balances are > provided through the means to petition at various points in the PDP. > While I realize this overview isn't policy, I do think that we should find a way to clarify the meaning of "staff/legal assessments before discussion". The way this paragraph reads, one could be under the impression that the intent is to prevent any discussion on PPML prior to these assessments. I know that the real intent is to have these assessments prior to formal discussion and I also realize that is what is in the actual policy. However, this paragraph could create confusion and stifle early discussion on PPML as a result. > THE PETITION PROCESS > > At each point in the process where a decision is made there is a means > for this decision to be overruled. > > 1. Submittal Petition. [10 days, maximum] > > If the staff and originator cannot reach an agreement on clear and > understandable text, the originator may make a Submittal Petition and > send the proposal to PPML and request community support to have the > proposal forwarded to the AC for review. The originator is responsible > for initiating the petition on the PPML (within 5 business days of a > good faith effort to reach agreement or after the end of the process > time limit for this step); the message must include the proposal and a > petition statement. The petition duration is 5 business days. The ARIN > President determines if the petition succeeds. Success is support from > at least 5 different people from 5 different organizations. > I am having trouble understanding the timeframes in this paragraph. How does one define the end of a good faith effort to reach agreement or the end of the process time limit for this step? Also, there seems a disconnect between the 5 business days spelled out throughout the paragraph and the 10 days mentioned in the title. This concern exists with each of the subsequent petition levels as well. The requirement for support of 5 people from 5 organizations seems a higher threshold than current process in that the first level of the current process requires 4 people from different organizations. The current process first petition point is essentially analogous to the next step. I would like to see the petition threshold at this level kept fairly low. I would propose something along the lines of: Upon failure of the staff and the originator to reach agreement on clear and understandable text, the originator may initiate a submittal petition. A submittal petition must be posted on PPML and must include the proposal and a petition statement. The petition duration is 5 business days. The ARIN president determines if a petition succeeds. Success shall require support from at least 3 different people from 3 different organizations. > 2. Discussion Petition. [10 days, maximum] > > If any member of the community, including a proposal originator, is > dissatisfied with the AC action on a policy proposal they can > initiate a > Discussion Petition to move this particular proposal to the PPML for > discussion as a draft policy. Anyone may initiate the petition on the > PPML (within 5 business days of publication of the AC's decision or > after the end of the process time limit for this step); the petition > must include the proposal and a petition statement. The petition > duration is 5 business days. The ARIN President determines if the > petition succeeds. Success is support from at least 10 different > people > from 10 different organizations. > I would like to see the threshold here lower as well. I think at this step 5 different people from 5 different organizations, which is a slightly higher bar than the current (4) process would be reasonable, but, I would also accept 4 to create parity with the current process. > 3. Last Call Petition. [10 days, maximum] > > If any member of the community, including a proposal originator, is > dissatisfied with the AC action on a draft policy they can initiate a > Last Call Petition to move this particular draft policy to the PPML > for > last call. Anyone may initiate the petition on the PPML (within 5 > business days of the publication of the AC's decision or after the end > of the process time limit for this step); the petition must include > the > draft policy and a petition statement. The petition duration is 5 > business days. The ARIN President determines if the petition succeeds. > Success is support from at least 10 different people from 10 different > organizations. > This seems reasonable to me. > 4. Board of Trustees Consideration Petition. [10 days, maximum] > > If any member of the community is dissatisfied with the AC action on a > draft policy they can initiate a Board of Trustees Consideration > Petition to move this particular draft policy for consideration by the > Board of Trustees. Anyone may initiate the petition on the PPML > (within > 5 business days of the publication of the AC's decision or after the > end > of the process time limit for this step); the petition must include > the > draft policy and a petition statement. The petition duration is 5 > business days. The ARIN President determines if the petition succeeds. > Success is support from at least 10 different people from 10 different > organizations. At this level, I can accept 10, but, I think that it might be worth considering a longer timeframe and a somewhat higher threshold. Perhaps a 15 business day consideration period with a requirement for 15 or 20 people from not less than 10 different organizations. Owen From bicknell at ufp.org Thu May 8 12:04:00 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 8 May 2008 12:04:00 -0400 Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9 May In-Reply-To: <7D8CF6AE-B21B-4EDF-B6B6-363FF7CEA954@delong.com> References: <4822EE3C.1000800@arin.net> <7D8CF6AE-B21B-4EDF-B6B6-363FF7CEA954@delong.com> Message-ID: <20080508160400.GA35446@ussenterprise.ufp.org> In a message written on Thu, May 08, 2008 at 08:39:48AM -0700, Owen DeLong wrote: > While I realize this overview isn't policy, I do think that we should > find a > way to clarify the meaning of "staff/legal assessments before > discussion". Perhaps: staff/legal assessments before discussion of a formal policy proposal I think the bit that is unclear here is that the proposal (and existing IRPEP) handle the process by which proposals get a formal number (e.g. 2008-1) and how, once they have that number, formal discussion is handeled; both on PPML and at the meeting. That process needs to be relatively formal to insure that all parties get to discuss fairly. However, it's also essentially orthogonal to the informal discussion process. PPML, Open Policy Hour, and the Open Mike all allow discussion of things that do not have formal numbers, and there is no proposal on the table to change any of those three venues. In summary, the processes look like: Today Proposed 1. Informal Discussion Informal Discussion 2. Submission to policy at arin.net Submission to policy at arin.net 3. IRPEP Kicks In Newly Proposed PDP Kicks In Another alternative would be to add at the top of the policy something like: Prior to submitting a policy to policy at arin.net submitters are encouraged to discuss ideas on PPML, during the open policy hour, or at the open mike during the public policy meeting. -- 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: 187 bytes Desc: not available URL: From Daniel_Alexander at Cable.Comcast.com Fri May 9 08:59:14 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 9 May 2008 08:59:14 -0400 Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9May References: <4822EE3C.1000800@arin.net> Message-ID: <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> This is only my opinion, but I feel step 1b should be modified. This step allows for a review period between the originator and ARIN staff with a max of 15 days to address issues. If issues cannot be resolved, the originator may utilize the petition process to move the proposal forward to the AC. I think this is overly complicated, and the petition process should not be involved in this step. This is because the petition process should not be required for an originator to get a proposal presented to the AC, that they elected to represent the community. While the experience of ARIN staff is extremely valuable, it is contradictory to the bottom up process that staff have the ability to deny a community proposal, even if the petition process is available. It just paints an awkward picture. It would be cleaner if the staff had the 15 day review period to try and resolve any issues, and then forward it on for the AC to consider. My two cents, Dan Alexander ARIN AC ________________________________ From: arin-ppml-bounces at arin.net on behalf of Member Services Sent: Thu 5/8/2008 8:12 AM To: arin-ppml at arin.net Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9May Recent comments on the PPML have requested more detail regarding the petition process. The proposed Policy Development Process (PDP) increases the number of petition points from two (2) to four (4). The threshold levels and process activity for these petitions are in consonance with the existing petition process. The details of the petition process are provided in the text below. REMINDER: Please post your opinions to arin-ppml at arin.net no later than 5 PM EDT, Friday, 9 May 2008. Regards, Member Services American Registry for Internet Numbers (ARIN) ****************************************************** OVERVIEW The proposed PDP is intended to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments before discussion; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption. The proposed PDP empowers the ARIN Advisory Council by shifting its scope from a policy advisory body to a policy development body while providing checks and balances and maintains an open and transparent process. The checks and balances are provided through the means to petition at various points in the PDP. THE PETITION PROCESS At each point in the process where a decision is made there is a means for this decision to be overruled. 1. Submittal Petition. [10 days, maximum] If the staff and originator cannot reach an agreement on clear and understandable text, the originator may make a Submittal Petition and send the proposal to PPML and request community support to have the proposal forwarded to the AC for review. The originator is responsible for initiating the petition on the PPML (within 5 business days of a good faith effort to reach agreement or after the end of the process time limit for this step); the message must include the proposal and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 5 different people from 5 different organizations. 2. Discussion Petition. [10 days, maximum] If any member of the community, including a proposal originator, is dissatisfied with the AC action on a policy proposal they can initiate a Discussion Petition to move this particular proposal to the PPML for discussion as a draft policy. Anyone may initiate the petition on the PPML (within 5 business days of publication of the AC's decision or after the end of the process time limit for this step); the petition must include the proposal and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 10 different people from 10 different organizations. 3. Last Call Petition. [10 days, maximum] If any member of the community, including a proposal originator, is dissatisfied with the AC action on a draft policy they can initiate a Last Call Petition to move this particular draft policy to the PPML for last call. Anyone may initiate the petition on the PPML (within 5 business days of the publication of the AC's decision or after the end of the process time limit for this step); the petition must include the draft policy and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 10 different people from 10 different organizations. 4. Board of Trustees Consideration Petition. [10 days, maximum] If any member of the community is dissatisfied with the AC action on a draft policy they can initiate a Board of Trustees Consideration Petition to move this particular draft policy for consideration by the Board of Trustees. Anyone may initiate the petition on the PPML (within 5 business days of the publication of the AC's decision or after the end of the process time limit for this step); the petition must include the draft policy and a petition statement. The petition duration is 5 business days. The ARIN President determines if the petition succeeds. Success is support from at least 10 different people from 10 different organizations. ********************************************* _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From BillD at cait.wustl.edu Fri May 9 10:10:43 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 9 May 2008 09:10:43 -0500 Subject: [arin-ppml] Proposed Petition Process for New PDP -- CommentsDue 9May In-Reply-To: <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> References: <4822EE3C.1000800@arin.net> <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> Message-ID: I agree totally with this... bd > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel > Sent: Friday, May 09, 2008 7:59 AM > To: Member Services; arin-ppml at arin.net > Subject: Re: [arin-ppml] Proposed Petition Process for New > PDP -- CommentsDue 9May > > This is only my opinion, but I feel step 1b should be > modified. This step allows for a review period between the > originator and ARIN staff with a max of 15 days to address > issues. If issues cannot be resolved, the originator may > utilize the petition process to move the proposal forward to the AC. > > I think this is overly complicated, and the petition process > should not be involved in this step. This is because the > petition process should not be required for an originator to > get a proposal presented to the AC, that they elected to > represent the community. While the experience of ARIN staff > is extremely valuable, it is contradictory to the bottom up > process that staff have the ability to deny a community > proposal, even if the petition process is available. It just > paints an awkward picture. > > It would be cleaner if the staff had the 15 day review period > to try and resolve any issues, and then forward it on for the > AC to consider. > > My two cents, > > Dan Alexander > ARIN AC > > > ________________________________ > > From: arin-ppml-bounces at arin.net on behalf of Member Services > Sent: Thu 5/8/2008 8:12 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Proposed Petition Process for New PDP -- > Comments Due 9May > > > > Recent comments on the PPML have requested more detail > regarding the petition process. The proposed Policy > Development Process (PDP) increases the number of petition > points from two (2) to four (4). The threshold levels and > process activity for these petitions are in consonance with > the existing petition process. The details of the petition > process are provided in the text below. > > REMINDER: Please post your opinions to arin-ppml at arin.net > no later than 5 PM EDT, Friday, 9 > May 2008. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > ****************************************************** > > OVERVIEW > > The proposed PDP is intended to bring forth clear, > technically sound and useful policy; reduce overlapping > policy proposals; require both staff and legal assessments > before discussion; give adequate opportunity for discussion > prior to each public policy meeting; and provide a means of > review prior to possible adoption. The proposed PDP empowers > the ARIN Advisory Council by shifting its scope from a policy > advisory body to a policy development body while providing > checks and balances and maintains an open and transparent > process. The checks and balances are provided through the > means to petition at various points in the PDP. > > THE PETITION PROCESS > > At each point in the process where a decision is made there > is a means for this decision to be overruled. > > 1. Submittal Petition. [10 days, maximum] > > If the staff and originator cannot reach an agreement on > clear and understandable text, the originator may make a > Submittal Petition and send the proposal to PPML and request > community support to have the proposal forwarded to the AC > for review. The originator is responsible for initiating the > petition on the PPML (within 5 business days of a good faith > effort to reach agreement or after the end of the process > time limit for this step); the message must include the > proposal and a petition statement. The petition duration is 5 > business days. The ARIN President determines if the petition > succeeds. Success is support from at least 5 different people > from 5 different organizations. > > 2. Discussion Petition. [10 days, maximum] > > If any member of the community, including a proposal > originator, is dissatisfied with the AC action on a policy > proposal they can initiate a Discussion Petition to move this > particular proposal to the PPML for discussion as a draft > policy. Anyone may initiate the petition on the PPML (within > 5 business days of publication of the AC's decision or after > the end of the process time limit for this step); the > petition must include the proposal and a petition statement. > The petition duration is 5 business days. The ARIN President > determines if the petition succeeds. Success is support from > at least 10 different people from 10 different organizations. > > 3. Last Call Petition. [10 days, maximum] > > If any member of the community, including a proposal > originator, is dissatisfied with the AC action on a draft > policy they can initiate a Last Call Petition to move this > particular draft policy to the PPML for last call. Anyone may > initiate the petition on the PPML (within 5 business days of > the publication of the AC's decision or after the end of the > process time limit for this step); the petition must include > the draft policy and a petition statement. The petition > duration is 5 business days. The ARIN President determines if > the petition succeeds. > Success is support from at least 10 different people from 10 > different organizations. > > 4. Board of Trustees Consideration Petition. [10 days, maximum] > > If any member of the community is dissatisfied with the AC > action on a draft policy they can initiate a Board of > Trustees Consideration Petition to move this particular draft > policy for consideration by the Board of Trustees. Anyone may > initiate the petition on the PPML (within > 5 business days of the publication of the AC's decision or > after the end of the process time limit for this step); the > petition must include the draft policy and a petition > statement. The petition duration is 5 business days. The ARIN > President determines if the petition succeeds. > Success is support from at least 10 different people from 10 > different organizations. > > ********************************************* > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From owen at delong.com Fri May 9 10:42:34 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 9 May 2008 07:42:34 -0700 Subject: [arin-ppml] Proposed Petition Process for New PDP -- CommentsDue 9May In-Reply-To: References: <4822EE3C.1000800@arin.net> <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> Message-ID: While this differs from my earlier suggestion of lowering the petition threshold at this step, I think this is actually a better plan. Owen On May 9, 2008, at 7:10 AM, Bill Darte wrote: > I agree totally with this... > bd > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel >> Sent: Friday, May 09, 2008 7:59 AM >> To: Member Services; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Proposed Petition Process for New >> PDP -- CommentsDue 9May >> >> This is only my opinion, but I feel step 1b should be >> modified. This step allows for a review period between the >> originator and ARIN staff with a max of 15 days to address >> issues. If issues cannot be resolved, the originator may >> utilize the petition process to move the proposal forward to the AC. >> >> I think this is overly complicated, and the petition process >> should not be involved in this step. This is because the >> petition process should not be required for an originator to >> get a proposal presented to the AC, that they elected to >> represent the community. While the experience of ARIN staff >> is extremely valuable, it is contradictory to the bottom up >> process that staff have the ability to deny a community >> proposal, even if the petition process is available. It just >> paints an awkward picture. >> >> It would be cleaner if the staff had the 15 day review period >> to try and resolve any issues, and then forward it on for the >> AC to consider. >> >> My two cents, >> >> Dan Alexander >> ARIN AC >> >> >> ________________________________ >> >> From: arin-ppml-bounces at arin.net on behalf of Member Services >> Sent: Thu 5/8/2008 8:12 AM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Proposed Petition Process for New PDP -- >> Comments Due 9May >> >> >> >> Recent comments on the PPML have requested more detail >> regarding the petition process. The proposed Policy >> Development Process (PDP) increases the number of petition >> points from two (2) to four (4). The threshold levels and >> process activity for these petitions are in consonance with >> the existing petition process. The details of the petition >> process are provided in the text below. >> >> REMINDER: Please post your opinions to arin-ppml at arin.net >> no later than 5 PM EDT, Friday, 9 >> May 2008. >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> ****************************************************** >> >> OVERVIEW >> >> The proposed PDP is intended to bring forth clear, >> technically sound and useful policy; reduce overlapping >> policy proposals; require both staff and legal assessments >> before discussion; give adequate opportunity for discussion >> prior to each public policy meeting; and provide a means of >> review prior to possible adoption. The proposed PDP empowers >> the ARIN Advisory Council by shifting its scope from a policy >> advisory body to a policy development body while providing >> checks and balances and maintains an open and transparent >> process. The checks and balances are provided through the >> means to petition at various points in the PDP. >> >> THE PETITION PROCESS >> >> At each point in the process where a decision is made there >> is a means for this decision to be overruled. >> >> 1. Submittal Petition. [10 days, maximum] >> >> If the staff and originator cannot reach an agreement on >> clear and understandable text, the originator may make a >> Submittal Petition and send the proposal to PPML and request >> community support to have the proposal forwarded to the AC >> for review. The originator is responsible for initiating the >> petition on the PPML (within 5 business days of a good faith >> effort to reach agreement or after the end of the process >> time limit for this step); the message must include the >> proposal and a petition statement. The petition duration is 5 >> business days. The ARIN President determines if the petition >> succeeds. Success is support from at least 5 different people >> from 5 different organizations. >> >> 2. Discussion Petition. [10 days, maximum] >> >> If any member of the community, including a proposal >> originator, is dissatisfied with the AC action on a policy >> proposal they can initiate a Discussion Petition to move this >> particular proposal to the PPML for discussion as a draft >> policy. Anyone may initiate the petition on the PPML (within >> 5 business days of publication of the AC's decision or after >> the end of the process time limit for this step); the >> petition must include the proposal and a petition statement. >> The petition duration is 5 business days. The ARIN President >> determines if the petition succeeds. Success is support from >> at least 10 different people from 10 different organizations. >> >> 3. Last Call Petition. [10 days, maximum] >> >> If any member of the community, including a proposal >> originator, is dissatisfied with the AC action on a draft >> policy they can initiate a Last Call Petition to move this >> particular draft policy to the PPML for last call. Anyone may >> initiate the petition on the PPML (within 5 business days of >> the publication of the AC's decision or after the end of the >> process time limit for this step); the petition must include >> the draft policy and a petition statement. The petition >> duration is 5 business days. The ARIN President determines if >> the petition succeeds. >> Success is support from at least 10 different people from 10 >> different organizations. >> >> 4. Board of Trustees Consideration Petition. [10 days, maximum] >> >> If any member of the community is dissatisfied with the AC >> action on a draft policy they can initiate a Board of >> Trustees Consideration Petition to move this particular draft >> policy for consideration by the Board of Trustees. Anyone may >> initiate the petition on the PPML (within >> 5 business days of the publication of the AC's decision or >> after the end of the process time limit for this step); the >> petition must include the draft policy and a petition >> statement. The petition duration is 5 business days. The ARIN >> President determines if the petition succeeds. >> Success is support from at least 10 different people from 10 >> different organizations. >> >> ********************************************* >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact the ARIN Member Services Help Desk at >> 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 the ARIN Member Services Help Desk at >> 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From lea.roberts at stanford.edu Fri May 9 10:47:16 2008 From: lea.roberts at stanford.edu (Lea Roberts) Date: Fri, 9 May 2008 07:47:16 -0700 (PDT) Subject: [arin-ppml] Proposed Petition Process for New PDP -- CommentsDue 9May In-Reply-To: Message-ID: On Fri, 9 May 2008, Bill Darte wrote: > I agree totally with this... +1 /Lea > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel > > Sent: Friday, May 09, 2008 7:59 AM > > To: Member Services; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Proposed Petition Process for New > > PDP -- CommentsDue 9May > > > > This is only my opinion, but I feel step 1b should be > > modified. This step allows for a review period between the > > originator and ARIN staff with a max of 15 days to address > > issues. If issues cannot be resolved, the originator may > > utilize the petition process to move the proposal forward to the AC. > > > > I think this is overly complicated, and the petition process > > should not be involved in this step. This is because the > > petition process should not be required for an originator to > > get a proposal presented to the AC, that they elected to > > represent the community. While the experience of ARIN staff > > is extremely valuable, it is contradictory to the bottom up > > process that staff have the ability to deny a community > > proposal, even if the petition process is available. It just > > paints an awkward picture. > > > > It would be cleaner if the staff had the 15 day review period > > to try and resolve any issues, and then forward it on for the > > AC to consider. > > > > My two cents, > > > > Dan Alexander > > ARIN AC From bicknell at ufp.org Fri May 9 10:56:03 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 9 May 2008 10:56:03 -0400 Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9May In-Reply-To: <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> References: <4822EE3C.1000800@arin.net> <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> Message-ID: <20080509145603.GA6536@ussenterprise.ufp.org> In a message written on Fri, May 09, 2008 at 08:59:14AM -0400, Alexander, Daniel wrote: > I think this is overly complicated, and the petition process > should not be involved in this step. This is because the petition > process should not be required for an originator to get a proposal > presented to the AC, that they elected to represent the community. > While the experience of ARIN staff is extremely valuable, it is > contradictory to the bottom up process that staff have the ability > to deny a community proposal, even if the petition process is > available. It just paints an awkward picture. My understand of the reason for this step was to make sure staff understood the proposal. They would make no evaluation of the merit of the proposal, simply if they understood the proposal as written. The idea being of course, if staff doesn't understand the proposal it makes little sense for everyone else to spend time debating it since one of two outcomes is likely, it will be rewritten so staff can understand it, or it would be passed and staff would have no idea how to implement it as they don't understand it. That said, if the alternative you propose is that the staff performs their review (15 day window) and then simply sends the proposal to the AC with "we understand it" or "we don't understand it" and the AC uses that as one of the inputs to the decision to accept or reject the proposal then I could support that as well. The most likely outcome to me though is that it results in a delay to the authors, rather than the staff sending back e-mail in the 15 day window saying "we don't understand" it will have to wait for the next AC meeting for the AC to say "we reject the proposal because the staff can't understand it". Not a huge worry on my part, but something to point out. -- 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: 187 bytes Desc: not available URL: From BillD at cait.wustl.edu Fri May 9 11:38:21 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 9 May 2008 10:38:21 -0500 Subject: [arin-ppml] Proposed Petition Process for New PDP -- CommentsDue 9May In-Reply-To: <20080509145603.GA6536@ussenterprise.ufp.org> References: <4822EE3C.1000800@arin.net><997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> <20080509145603.GA6536@ussenterprise.ufp.org> Message-ID: Understood. But, the point here is one of perception. If staff can't resolve then the AC doesn't get it and the petition process is invoked....perception may be that staff rejected it. Bad karma. If staff can't resolve and AC gets it and can't resolve...all of the above is true, but the elected representatives have done it.... As is their role. bd > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell > Sent: Friday, May 09, 2008 9:56 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Proposed Petition Process for New > PDP -- CommentsDue 9May > > In a message written on Fri, May 09, 2008 at 08:59:14AM > -0400, Alexander, Daniel wrote: > > I think this is overly complicated, and the petition process should > > not be involved in this step. This is because the petition process > > should not be required for an originator to get a proposal > presented > > to the AC, that they elected to represent the community. > > While the experience of ARIN staff is extremely valuable, it is > > contradictory to the bottom up process that staff have the > ability to > > deny a community proposal, even if the petition process is > available. > > It just paints an awkward picture. > > My understand of the reason for this step was to make sure > staff understood the proposal. They would make no evaluation > of the merit of the proposal, simply if they understood the > proposal as written. > > The idea being of course, if staff doesn't understand the > proposal it makes little sense for everyone else to spend > time debating it since one of two outcomes is likely, it will > be rewritten so staff can understand it, or it would be > passed and staff would have no idea how to implement it as > they don't understand it. > > That said, if the alternative you propose is that the staff > performs their review (15 day window) and then simply sends > the proposal to the AC with "we understand it" or "we don't > understand it" and the AC uses that as one of the inputs to > the decision to accept or reject the proposal then I could > support that as well. The most likely outcome to me though > is that it results in a delay to the authors, rather than the > staff sending back e-mail in the 15 day window saying "we > don't understand" it will have to wait for the next AC > meeting for the AC to say "we reject the proposal because the > staff can't understand it". Not a huge worry on my part, but > something to point out. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > From weiler at tislabs.com Fri May 9 11:40:56 2008 From: weiler at tislabs.com (Sam Weiler) Date: Fri, 9 May 2008 11:40:56 -0400 (EDT) Subject: [arin-ppml] Proposed Revision to the ARIN Policy Development Process Message-ID: [resending; sorry for any duplicates] In general, I support these proposed changes -- I think they'll result in better policy proposals, which helps us all. Thanks to the board for proposing them. But the specifics need some work. First, this proposal doesn't do enough to 1) make the process more responsive and 2) make the PPML more relevant (and, by implication, the physical public policy meetings less dominant in the policy process). As a first step, I suggest allowing the AC (or a petitioner) discretion to advance a policy without discussion at a meeting. I look forward to other suggestions the community may have towards these ends, also. Second, I agree with Owen that the petition threshholds are too high. The first petition step should be removed, as others have suggested. The second should be no higher than the current threshold, at 4. I'm dubious about the value of adding another petition step (beyond the existing two). Can we dodge one of the last two steps entirely and, much like the current IRPEP, have anything that passes a last call petition go directly to the board (or go to the board at the discretion of the successful petitioner)? Third, I think the document needs some editorial attention, possibly from counsel, prior to adoption. I'm also happy to work with the editor. -- Sam From dlw+arin at tellme.com Fri May 9 12:18:39 2008 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 9 May 2008 09:18:39 -0700 Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9May In-Reply-To: <20080509145603.GA6536@ussenterprise.ufp.org> References: <4822EE3C.1000800@arin.net> <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> <20080509145603.GA6536@ussenterprise.ufp.org> Message-ID: <20080509161839.GK13230@shell01.cell.sv2.tellme.com> I'd support Leo's proposed modification. I agree that having an initial step that looks like staff approval, even if that's not the actual intent, is going to be a major perception problem. Some modification is probably necessary to fix that perception gap, but verifying that staff understands the proposal is, as Leo notes, an important step. I'm otherwise generally in favor of the proposal as written. It may need some tweaking down the road, but I don't think we'll really know that until we try to use this process. Question for Scott and the board: is there yet any specific ideas on when and how this process will be adopted? I'd hate to see different proceses used for different proposals, based on the timing of the initial proposal, as that seems likely to cause a lot of confusion. On the other hand, changing the criteria for acceptance for a proposal that's already in process seems unfair. As near as I can tell, the process used to generate policy is entirely owned by the board, so I'm hoping that the smart people we elected have some thoughts on this problem. -David On Fri, May 09, 2008 at 10:56:03AM -0400, Leo Bicknell wrote: > In a message written on Fri, May 09, 2008 at 08:59:14AM -0400, Alexander, Daniel wrote: > > I think this is overly complicated, and the petition process > > should not be involved in this step. This is because the petition > > process should not be required for an originator to get a proposal > > presented to the AC, that they elected to represent the community. > > While the experience of ARIN staff is extremely valuable, it is > > contradictory to the bottom up process that staff have the ability > > to deny a community proposal, even if the petition process is > > available. It just paints an awkward picture. > > My understand of the reason for this step was to make sure staff > understood the proposal. They would make no evaluation of the merit > of the proposal, simply if they understood the proposal as written. > > The idea being of course, if staff doesn't understand the proposal > it makes little sense for everyone else to spend time debating it > since one of two outcomes is likely, it will be rewritten so staff > can understand it, or it would be passed and staff would have no > idea how to implement it as they don't understand it. > > That said, if the alternative you propose is that the staff performs > their review (15 day window) and then simply sends the proposal to > the AC with "we understand it" or "we don't understand it" and the > AC uses that as one of the inputs to the decision to accept or > reject the proposal then I could support that as well. The most likely > outcome to me though is that it results in a delay to the authors, > rather than the staff sending back e-mail in the 15 day window saying > "we don't understand" it will have to wait for the next AC meeting for > the AC to say "we reject the proposal because the staff can't understand > it". Not a huge worry on my part, but something to point out. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From bnkuerbi at syr.edu Fri May 9 14:51:03 2008 From: bnkuerbi at syr.edu (Brenden Kuerbis) Date: Fri, 9 May 2008 14:51:03 -0400 Subject: [arin-ppml] Proposed Revision to the ARIN Policy Development Process In-Reply-To: References: Message-ID: <28cfc1a40805091151x1f2799di6b863a45fa5dbb82@mail.gmail.com> Hi, Hoping the list will consider some comments from an observer of Internet governance processes. I would echo the concerns voiced, real or imagined, about staff influence in the proposed PDP. The initial staff review of an originator's proposal should not unduly influence whether the proposal advances for consideration by an elected body. (Actually, while I understand the intent, I'm not sure why such a staff check is even needed at this point. Any originator who _really_ wants their proposal to be considered seriously has incentive to work with staff to get language correct, etc., right?) The broader institutional-design point is you want to ensure that accountable bodies (like the AC and Board) are making decisions in the PDP, and that their accountability is closely linked to those affected by public policy (i.e., the community). A related point in support of Sam Weiler's comments about responsiveness and leveraging distributed communication tools (like the PPML). Would it make sense once the actual process and rules are determined to use a tool like the Sunlight Foundation's PublicMarkup project < http://publicmarkup.org/about/> or similar? Mailing lists, as critical as they are for remaining in contact, don't strike me as a great choice for distributed markup of complex issues. A combination of tools used might make more sense, increasing transparency, participation in all phases of the proposed PDP. If you're interested, PublicMarkup.org code < http://publicmarkup.org/about/code/> (I have no affiliation). Best regards, -- Brenden Kuerbis Internet Governance Project http://internetgovernance.org On Fri, May 9, 2008 at 11:40 AM, Sam Weiler wrote: > [resending; sorry for any duplicates] > > In general, I support these proposed changes -- I think they'll result > in better policy proposals, which helps us all. Thanks to the board > for proposing them. > > But the specifics need some work. > > First, this proposal doesn't do enough to 1) make the process more > responsive and 2) make the PPML more relevant (and, by implication, > the physical public policy meetings less dominant in the policy > process). As a first step, I suggest allowing the AC (or a > petitioner) discretion to advance a policy without discussion at a > meeting. I look forward to other suggestions the community may have > towards these ends, also. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schiller at uu.net Fri May 9 15:33:59 2008 From: schiller at uu.net (Jason Schiller) Date: Fri, 09 May 2008 15:33:59 -0400 (EDT) Subject: [arin-ppml] Proposed Revision to the ARIN Policy Development Process In-Reply-To: Message-ID: On Fri, 9 May 2008, Sam Weiler wrote: > Date: Fri, 09 May 2008 11:40:56 -0400 (EDT) > From: Sam Weiler > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Proposed Revision to the ARIN Policy Development > Process > > [resending; sorry for any duplicates] > > In general, I support these proposed changes -- I think they'll result > in better policy proposals, which helps us all. Thanks to the board > for proposing them. > > But the specifics need some work. > > First, this proposal doesn't do enough to 1) make the process more > responsive and 2) make the PPML more relevant (and, by implication, > the physical public policy meetings less dominant in the policy > process). As a first step, I suggest allowing the AC (or a > petitioner) discretion to advance a policy without discussion at a > meeting. I look forward to other suggestions the community may have > towards these ends, also. > In general, support the idea of empowering the AC to do policy development. I expect that this will lead to a smaller number of better written proposals, a reduction of similar but conflicting policies, and a reduction of policies that are not technically sound, or have a very narrow benefit. I also believe doing staff and legal assessments earlier is a positive change. Having adequate discussion of the proposed policy and being able to refine and freeze the text prior to the Public Policy Meeting is a noble goal, but I do not believe the current discussion (unless the process is somehow changed) on the PPML list is adequate to accomplish this as evidence by the fact that many recent policy proposals resulted in quibbling about text. My concerns are similar to Sam's wrt making the process more responsive, and making the ARIN community more relevant. In the Public Policy Meeting I expressed my concerns about the likelihood that the AC would make attempts to work with reasonable authors at each stage of the process. This would encourage the AC and the originator to find common ground, and reduce the likelihood of policy proposals going through the petition process. As a result, I would feel more comfortable with a higher bar for the petition process, and even if the bar is not raised, there would still likely be a reduction of multiple similar policies being presented before the community. Wrt the petition process I think the community should be able to petition at each step where the AC might decide to act contrary to the community or orignator. How difficult the petition process should be should be indirectly proportional to how likely the AC is to work with the originator or community in general. It was my impression that the AC intends to make a reasonable effort to work with the originator. It was also my impression that the intention of the process was for the AC to attempt to work with the originator. Unfortunately the text only references the AC working with the originator during the clarity and understanding phase (1b.). I would like the AC to make an attempt to work with reasonable originators at each of the steps: draft policy rewrite/merge/abandon/etc (2a), draft policy selection (2b), presentation at the Policy Meeting (4), Consensus rewrite/merge/abandon send to last call/etc (5a). For example, if the AC believes the originator can do a better presentation of the proposed policy is that acceptable? Will the AC collaborate with the originator to get input for the presentation at the Public Policy Meeting? Will the AC make the final presentation to the Public Policy Meeting available to originator prior to the meeting to solicit feed back? For example will the AC attempt consult the originator on rewrites to see if they can reasonably reach some text that is mutually acceptable to the originator and the AC? Some other clarification is also requested: If a policy is a draft policy (2b) but does not get selected, does it remain a draft policy? What happens at the maximum of 30 days? Does the draft policy then expire? Or does the AC simply have to decide if they are or are not going to select it in a 30 day window? If the latter is true, can that later select a draft policy after 30 days? In last call (5b) the AC selects draft policies that have support in both the community and the AC. Is there any way for the community to gain insight as to if a particular draft policy does or does not have consensus within the AC? Is there any ability for the community to understand the AC reservations, and attempt to address them in order to win support? In last call review (5c) what happens if the draft policy is placed back on the docket? Does it proceed directly to step 2a? Thanks, ___Jason From farmer at umn.edu Fri May 9 16:09:14 2008 From: farmer at umn.edu (David Farmer) Date: Fri, 09 May 2008 15:09:14 -0500 Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9May In-Reply-To: <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> References: <4822EE3C.1000800@arin.net>, <997BC128AE961E4A8B880CD7442D9480D78A3D@NJCHLEXCMB01.cable.comcast.com> Message-ID: <4824691A.21354.48F2FBE@farmer.umn.edu> I see the point about the perception that the staff may be holding up some thing, and I agree it would be good to avoid that perception. However, I think there are other reasons to still have this step. This is not the only check on Staff interference there are other remedies through executive oversight by the board, especially if there is a chronic issue. But, this step could be important to deal with process abuse by a member of the community. If the staff finds that a policy is is not clear and the author or originator can't find some minimal support thorough the PPML, then why is it a good use of limited AC resources to even consider it further? In Robert's Rules of Order, Motions are generally required to be seconded, a primary reason for this is to insure that there is at least someone else supporting the Motion before it is considered, and to insure no single person can abuse the process. The Second is generally a formality, almost always someone Seconds a Motion, but every once and a while a Motion get no Second and the Motion is Lost. So I would prefer as Owen originally proposed that the step be preserved but the threshold lowered, I'd say maybe even down to two or even one other person(s) from a different organization(s). Basically, if you can't get someone to second the motion why should it be considered. Additionally, if the issue is an important one, even if it can't clearly and concisely articulate, the community will likely make that evident through this step. Just a thought before the land slides out from under this step. On 9 May 2008 Alexander, Daniel wrote: > This is only my opinion, but I feel step 1b should be modified. This > step allows for a review period between the originator and ARIN staff > with a max of 15 days to address issues. If issues cannot be resolved, > the originator may utilize the petition process to move the proposal > forward to the AC. > > I think this is overly complicated, and the petition process should > not be involved in this step. This is because the petition process > should not be required for an originator to get a proposal presented > to the AC, that they elected to represent the community. While the > experience of ARIN staff is extremely valuable, it is contradictory to > the bottom up process that staff have the ability to deny a community > proposal, even if the petition process is available. It just paints an > awkward picture. > > It would be cleaner if the staff had the 15 day review period to try > and resolve any issues, and then forward it on for the AC to consider. > > My two cents, > > Dan Alexander > ARIN AC > > > ________________________________ > > From: arin-ppml-bounces at arin.net on behalf of Member Services > Sent: Thu 5/8/2008 8:12 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Proposed Petition Process for New PDP -- Comments Due 9May > > > > Recent comments on the PPML have requested more detail regarding the > petition process. The proposed Policy Development Process (PDP) > increases the number of petition points from two (2) to four (4). The > threshold levels and process activity for these petitions are in > consonance with the existing petition process. The details of the > petition process are provided in the text below. > > REMINDER: Please post your opinions to arin-ppml at arin.net > no later than 5 PM EDT, Friday, 9 May 2008. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > ****************************************************** > > OVERVIEW > > The proposed PDP is intended to bring forth clear, technically sound and > useful policy; reduce overlapping policy proposals; require both staff > and legal assessments before discussion; give adequate opportunity for > discussion prior to each public policy meeting; and provide a means of > review prior to possible adoption. The proposed PDP empowers the ARIN > Advisory Council by shifting its scope from a policy advisory body to a > policy development body while providing checks and balances and > maintains an open and transparent process. The checks and balances are > provided through the means to petition at various points in the PDP. > > THE PETITION PROCESS > > At each point in the process where a decision is made there is a means > for this decision to be overruled. > > 1. Submittal Petition. [10 days, maximum] > > If the staff and originator cannot reach an agreement on clear and > understandable text, the originator may make a Submittal Petition and > send the proposal to PPML and request community support to have the > proposal forwarded to the AC for review. The originator is responsible > for initiating the petition on the PPML (within 5 business days of a > good faith effort to reach agreement or after the end of the process > time limit for this step); the message must include the proposal and a > petition statement. The petition duration is 5 business days. The ARIN > President determines if the petition succeeds. Success is support from > at least 5 different people from 5 different organizations. > > 2. Discussion Petition. [10 days, maximum] > > If any member of the community, including a proposal originator, is > dissatisfied with the AC action on a policy proposal they can initiate a > Discussion Petition to move this particular proposal to the PPML for > discussion as a draft policy. Anyone may initiate the petition on the > PPML (within 5 business days of publication of the AC's decision or > after the end of the process time limit for this step); the petition > must include the proposal and a petition statement. The petition > duration is 5 business days. The ARIN President determines if the > petition succeeds. Success is support from at least 10 different people > from 10 different organizations. > > 3. Last Call Petition. [10 days, maximum] > > If any member of the community, including a proposal originator, is > dissatisfied with the AC action on a draft policy they can initiate a > Last Call Petition to move this particular draft policy to the PPML for > last call. Anyone may initiate the petition on the PPML (within 5 > business days of the publication of the AC's decision or after the end > of the process time limit for this step); the petition must include the > draft policy and a petition statement. The petition duration is 5 > business days. The ARIN President determines if the petition succeeds. > Success is support from at least 10 different people from 10 different > organizations. > > 4. Board of Trustees Consideration Petition. [10 days, maximum] > > If any member of the community is dissatisfied with the AC action on a > draft policy they can initiate a Board of Trustees Consideration > Petition to move this particular draft policy for consideration by the > Board of Trustees. Anyone may initiate the petition on the PPML (within > 5 business days of the publication of the AC's decision or after the end > of the process time limit for this step); the petition must include the > draft policy and a petition statement. The petition duration is 5 > business days. The ARIN President determines if the petition succeeds. > Success is support from at least 10 different people from 10 different > organizations. > > ********************************************* > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626- 0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From randy at psg.com Fri May 9 18:47:34 2008 From: randy at psg.com (Randy Bush) Date: Sat, 10 May 2008 00:47:34 +0200 Subject: [arin-ppml] Proposed Revision to the ARIN Policy Development Process In-Reply-To: <28cfc1a40805091151x1f2799di6b863a45fa5dbb82@mail.gmail.com> References: <28cfc1a40805091151x1f2799di6b863a45fa5dbb82@mail.gmail.com> Message-ID: <4824D486.7020807@psg.com> Brenden Kuerbis wrote: > The initial staff review of an originator's proposal should not > unduly influence whether the proposal advances for consideration by > an elected body. (Actually, while I understand the intent, I'm not > sure why such a staff check is even needed at this point. this is the actual internet. we deal with actual operational reality, not just ersatz egalitarian academic bs. randy From jcurran at istaff.org Fri May 9 19:13:11 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 9 May 2008 19:13:11 -0400 Subject: [arin-ppml] Proposed Revision to the ARIN Policy Development Process In-Reply-To: <28cfc1a40805091151x1f2799di6b863a45fa5dbb82@mail.gmail.com> References: <28cfc1a40805091151x1f2799di6b863a45fa5dbb82@mail.gmail.com> Message-ID: At 2:51 PM -0400 5/9/08, Brenden Kuerbis wrote: >I would echo the concerns voiced, real or imagined, about staff influence in the proposed PDP. The initial staff review of an originator's proposal should not unduly influence whether the proposal advances for consideration by an elected body. (Actually, while I understand the intent, I'm not sure why such a staff check is even needed at this point. Any originator who _really_ wants their proposal to be considered seriously has incentive to work with staff to get language correct, etc., right?) The goal of the staff review is to assist originator of the idea in formation of a clear policy proposal. In the past, we have had several occasions where the originator felt that their idea was quite clearly stated, but it turned out that the actual proposal language didn't accomplish what they expected, due to use of terminology differently than the rest of the policy manual or due to misunderstanding on existing practice in a given area. This has resulted in some very confusing discussions both on the mailing list and the public policy meeting. I agree with the intent that staff review shouldn't be a barrier to proposal consideration, but would also hope that a proposal originator would value the feedback regarding how their proposal language would be construed. /John From BillD at cait.wustl.edu Sun May 11 14:50:52 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Sun, 11 May 2008 13:50:52 -0500 Subject: [arin-ppml] Proposed Revision to the ARIN Policy Development Process References: Message-ID: Jason Schiller wrote.... snip Unfortunately the text only references the AC working with the originator during the clarity and understanding phase (1b.). I would like the AC to make an attempt to work with reasonable originators at each of the steps: draft policy rewrite/merge/abandon/etc (2a), draft policy selection (2b), presentation at the Policy Meeting (4), Consensus rewrite/merge/abandon send to last call/etc (5a). snip Thanks, ___Jason Among the AC we have discussed this very aspect among others. I assure you the sentiment among the AC is that we will continue to work with originator(s) and the public at large in this PDP. No one that I know of thinks other than this is a mechanism for making the process more efficient and effective, but NOT to abandon the public since that's who we represent! bd _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Mon May 12 10:33:54 2008 From: info at arin.net (Member Services) Date: Mon, 12 May 2008 10:33:54 -0400 Subject: [arin-ppml] Comments Received on Proposed Policy Development Process Message-ID: <48285552.9060307@arin.net> Thanks to everyone who submitted comments over the last two weeks concerning the new draft Policy Development Process. The ARIN Board will consider all the valuable input as it works with staff to finalize the text and consider implementation details. Regards, Member Services American Registry for Internet Numbers (ARIN) From Daniel_Alexander at Cable.Comcast.com Fri May 16 11:35:09 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 16 May 2008 11:35:09 -0400 Subject: [arin-ppml] Thinking of other options Message-ID: <997BC128AE961E4A8B880CD7442D948004FAA3AA@NJCHLEXCMB01.cable.comcast.com> Hello All, In an effort to spur some discussion on ppml, I wanted to offer the thought below. Regardless of whether there is a black market, or a paid transfer policy, it is very difficult to see a sufficient supply of IPv4 resources surface in an IANA depleted model, for the large ISP. This means that the large ISP will hit the wall first, and hit it the hardest. There is no way around the fact that this particular group already needs to be well into their transition plans, because they will be unable to obtain adequate amounts of IPv4 resources, in the foreseeable future. It is also this group who is more able to bear the burden of working with equipment vendors, and software developers, to push the necessary momentum towards IPv6. A preferred model would not be to prolong the availability of IPv4 resources, but rather to make sure all groups have reasonable access to these resources, until sufficient momentum has shifted towards IPv6. It is the largest IP consumers who will drive the vendors, and develop the market for IPv6 enabled equipment. It is the smallest organizations who need to remain on IPv4 until the shift has gained the necessary momentum. Unfortunately, it didn't matter that the teacher provided an extra week to study for the exam. The majority of the students never studied until the night before the test. The reality is the momentum towards IPv6 likely won't happen until after the IANA pool is depleted and the largest IP consumers hit the wall. Considering what has been mentioned so far, a number of possible policies are listed below. The intent of this email is to not focus on any one point, but to take the overall approach into consideration. The main consideration is to solidify how allocations are made to provide a window for those without resources to survive until those with the resources can build the necessary momentum in the marketplace. ===== Pre-IANA Depletion ===== * No paid transfer policy. * Allocation policies continue as they are. Based on need, proving prior utilization. * No more multiple accounts. An organization cannot create an additional orgid if the organization currently holds General Membership. * Legacy space considered. ARIN would look at legacy allocations when considering need for ARIN requested resources. This consideration would exist regardless of whether the legacy resource is associated to an orgid or under RSA. This is not about trying to reclaim any legacy resource. Only in justifying need for an ARIN allocated resource. === ARIN remaining reserve equivilent to a /8 === * Make the maximum allocation a /18. This would continue to serve the needs of 95% of the organizations needing address space. The top 5% of the consuming organizations could still get the max allocation, but would not be able to immediately deplete the remaining pool by being bound to the max window mentioned below. * Make the allocation window minimum six months. No matter the need, an org account cannot get an allocation more frequently than every six months. This would put the largest organizations on the hook first to move to IPv6, while buying time for the smaller orgs whose needs would continue to be met by the current policies. This could also stretch out the remaining IPv4 space for another year, which is not the goal, but allows for the momentum to occur where needed. ============================================ The other thought is that this may not eliminate the need for a paid transfer, but could eliminate a considerable amount of speculation and deaggregation. There is no need to shop around for smaller blocks when the needs of +90% of the market can be served by the Registry through normal allocations. The largest demand would be from the largest providers who would be spending the money for larger aggregates and/or to buy several smaller ones that can be put back together. By isolating the demand from the majority of the organizations, it could potentially play out that the largest organizations create the momentum towards IPv6 before the rest of the IP consumers need to turn to paid transfers. Some could argue that this impedes the larger organizations from equal access to resources, but they would have the same access as everyone else, in an environment of a depleted resource. Dan Alexander Comcast Cable ARIN AC From info at arin.net Fri May 16 14:50:47 2008 From: info at arin.net (Member Services) Date: Fri, 16 May 2008 14:50:47 -0400 Subject: [arin-ppml] Policy Proposal 2007-17: Last Call Message-ID: <482DD787.2070805@arin.net> Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation On 15 May 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that the community supports this proposal as edited and moves it to an extended last call. The AC made the following minor edits from the version that was presented at ARIN XXI in Denver Colorado: * The statement about the Board adopting incentives was taken out of the policy text and moved to the rationale section and will be sent as a note to the Board. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire at 23:59 EDT, 17 June April 2008. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_17.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Date: 16 May 2008 Proposal type: modify Policy term: permanent Policy statement: Replace section 4.6 as follows: 4.6 Amnesty and Aggregation requests 4.6.1 Intent of this policy This policy is intended to allow the community and ARIN staff to work together with holders of address resources in the best interests of the community by facilitating the return of unused address space and the aggregation of existing space in a manner which is in the best interests of both parties. All transactions under this policy must either create greater aggregation (a reduction in the number of prefixes) or the return of address space. ARIN should reject any transaction which staff judges is not in the interests of the community. 4.6.2 No penalty for returning or aggregating ARIN shall seek to make the return of address space as convenient and risk-free to the returning organization as possible. An organization with several non-contiguous blocks seeking to aggregate and return space at the same time should be accommodated if possible. If it is possible to expand one block, for example, to facilitate the return of other blocks, ARIN should do that. 4.6.3 Return should not force renumbering An organization shall be allowed to return a partial block of any size to ARIN. For any return greater than a /24, ARIN shall not require that the non-returned portion of the block be renumbered unless the returning organization wishes to do so. 4.6.4 Timeframe for return Any organization which is returning addresses under this policy shall negotiate with ARIN an appropriate timeframe in which to return the addresses after any new resources are received under this policy. In the case of a simple return, the timeframe shall be immediate. In the case where renumbering into new addresses out of existing addresses to be returned is required, the returning organization shall sign a contract with ARIN which stipulates a final return date not less than 6 months nor more than 18 months after the receipt of new addresses. If an organization misses this return date, but, ARIN believes the organization is working in good faith to complete the renumbering, ARIN may grant a single extension of 6-12 months as staff deems appropriate to the situation. Such an extension must be requested in writing (email to hostmaster at arin.net) by the organization at least 15 days prior to the original expiration date. 4.6.5 RSA Required if new addresses received Any organization which receives any additional addresses under this policy shall be required to sign an ARIN RSA which will apply to all new addresses issued and to any retained blocks which are expanded under this policy. 4.6.6 Annual contact required Any organization which participates in this policy shall be required to sign an agreement stipulating that ARIN will attempt contact at least once per year via the contact mechanisms registered for the organization in whois. Should ARIN fail to make contact, after reasonable effort the organization shall be flagged as "unreachable" in whois. After six months in "unreachable" status, the organization agrees that ARIN may consider all resources held by the organization to be abandoned and reclaim such resources. Should the organization make contact with ARIN prior to the end of the aforementioned six month period and update their contact information appropriately, ARIN shall remove the "unreachable" status and the annual contact cycle shall continue as normal. If the organization pays annual fees to ARIN, the payment of annual fees shall be considered sufficient contact. Rationale: Existing policy supports aggregation (4.7) and provides some amnesty (existing 4.6) for returning blocks. However, a number of resource holders have expressed discomfort with the current section 4.6 believing that they will be forced to return their entire address space and renumber rather than being able to make partial returns and retain some of their existing space. This policy seeks to eliminate those concerns and make the return of unused address space more desirable to the resource holders. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process and no way to return any portion of their address space without incurring significant disadvantage as a result. A suggestion to the board would be to adopt benefits along the following lines for people returning space. These benefits would provide additional incentive for resource holders to make appropriate returns and for legacy holders to join the ARIN process: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 returned, with any fractional /20 resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that their IPv4 resources are henceforth subject to the RSA. The overriding intent of this policy proposal is to make it as easy as possible for both ARIN and resource holders to "do the right thing" with regard to excess resources or dis-aggregated (fragmented) address blocks. It is the desire of the author that staff make any judgment calls necessary under this policy with that ideal clearly in mind. While the author has made a concerted effort to make the policy as clear as possible and as concrete as can be, the reality is that these types of transactions must rely heavily on the judgment and expertise of the ARIN staff in determining what is in the best interests of the community. Note to the board: The advisory council believes that the Board of Trustees should consider creating incentives for organizations to return addresses under this policy. This idea was part of the policy proposal as discussed by the membership, but, we (the AC) feel that it should not be part of the NRPM (fees are not policy matter) so we have pulled it out of the policy and moved it to this note. Timetable for implementation: Immediate From info at arin.net Fri May 16 14:51:42 2008 From: info at arin.net (Member Services) Date: Fri, 16 May 2008 14:51:42 -0400 Subject: [arin-ppml] Policy Proposal 2008-4: Minimum Allocation in the Caribbean Region Message-ID: <482DD7BE.8060104@arin.net> On 15 May 2008, the ARIN Advisory Council (AC) concluded its review of "Minimum Allocation in the Caribbean Region" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2008-4: Minimum Allocation in the Caribbean Region. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2008_4.html All persons in the community are encouraged to discuss Policy Proposal 2008-4 prior to it being presented at the ARIN XXII Public Policy Meeting. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-4 Minimum Allocation in the Caribbean Region Author: Cathy Aronson and Paul Andersen Date: 16 May 2008 Proposal type: new Policy term: renewable Policy statement: Minimum Allocation. The minimum IPv4 allocation size for ISPs from the Caribbean portion of the ARIN region is /22. 1. Allocation Criteria. A. The requesting organization must show the efficient utilization of an entire previously allocated /22 from their upstream ISP. This allocation (/22) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 4 /24s. B. A multi-homed organization must show the efficient utilization of an entire previously allocated /23 from their upstream ISP. This allocation (/23) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 2 /24s. 2. Utilization Reporting and Justification. All other ARIN policies regarding the reporting of justification information for the allocation of IPv4 and IPv6 address space will remain in effect. Rationale: ARIN staff have noted that organizations in the Caribbean region have problems meeting the current criteria due to the fact that the population in the region is smaller than that of Canada and the US. There is also a lack of competition with many countries in the region faced with a monopoly or duopoly situation in terms of transport providers. To spur development in the region a similar proposal was passed in this region for the portion of the African region that ARIN administered prior to the formation of AfriNIC. This proposal seeks a similar outcome. Timetable for implementation: immediate From info at arin.net Wed May 21 10:36:54 2008 From: info at arin.net (Member Services) Date: Wed, 21 May 2008 10:36:54 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out Message-ID: <48343386.4060700@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this 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. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Equitable Distribution of IPv4 Resources before IPv4 Run out Author: Michael K. Smith Proposal Version: 1 Submission Date: 05/20/2008 Proposal type: new Policy term: permanent Policy statement: Upon receipt of the last allocation of IPv4 address space to ARIN from IANA, ARIN will reserve address space within the allocated block for Organizations within the defined ARIN Organizational Size determinations (Extra Small, Small, Large, Extra Large) based upon the utilization percentages for each group gathered from the statistics of the last two IANA allocations to ARIN. In order to make the allocation percentages mathematically feasible, the percentages will be rounded to the closest whole number and, subsequently, the the closest bit boundary for assignment the maximum allocation size for the Organization size as defined by ARIN. Once the final IANA allocation is received, ARIN will publish the allocation percentages that will be used for the final allocation to the PPML and ARIN website with the necessary documentation supporting the assignment of percentages. Rationale: Description: This policy is designed to allow Organizations of the various defined sizes to continue to receive address allocations from the last available space and is slanted towards ensuring that organizations within the Large, Small and Extra Small groups (and more specifically, the Small and Extra Small groups) are able to get additional IPv4 space at the end of the ARIN's ability to allocate such space. Given the statistics below, it is likely that Extra Large Organizations would get most or all of the last remaining space because given the amount they have been allocated to date. This policy would help ensure that other Organizations had a statistically equal opportunity to receive space as well. Example: Please see http://www.arin.net/statistics/index.html (Note: the statistics are generated from IP allocations from 2006 and 2007). This policy would require statistics to be limited to the previous 2 IANA allocations to ARIN.) The present distribution as of May 20th 2008 is: Extra Large: 83.11% Large: 6.75% Small: 9.00% Extra Small: 1.14% With this example, ARIN would reserve address space in the final IANA allocation according to those percentages, to the extent that it is mathematically possible within the existing range. In order to make the math work, rounding would give us: Extra Large: 83% Large: 7% Small: 9% Extra Small: 1% Who is affected: All ARIN Members will be affected by this policy. I assume that smaller providers will benefit from having some space available to them beyond where they would be with an organic allocation model, and the Extra Large Organizations would experience some pain because, using the model above, they would be excluded from being allocated 17% of the remaining space, even if they had all of the necessary justifications for receiving allocations from within that space. Policy Enforcement: ARIN staff will have to enforce this policy and ensure that allocations stay within the published percentages. Financial and Liability Implications: Financially, there may be additional resources required by ARIN Staff to allocate resources using this model. These resources might include application development, staff training and tracking of allocations based upon the model. ARIN may have legal liability should Organizations that were denied space according to the model decide to contest the legality of the policy in court. Timetable for implementation: Upon receipt of finall IANA allocation (roughly 2011). From LSwanson at primetherapeutics.com Wed May 21 13:02:35 2008 From: LSwanson at primetherapeutics.com (LSwanson at primetherapeutics.com) Date: Wed, 21 May 2008 12:02:35 -0500 Subject: [arin-ppml] Swanson, Lisa is out of the office. Message-ID: I will be out of the office starting 05/20/2008 and will not return until 05/22/2008. I will be traveling to; and working in our Irving, Texas facility and have spotty access to e-mail and voicemail. Please contact the service desk for emergency assistance. Prime Therapeutics made the following annotations --------------------------------------------------------------------- CONFIDENTIALITY NOTICE: The information contained in this communication may be confidential, and is intended only for the use of the recipients named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. --------------------------------------------------------------------- From sleibrand at internap.com Wed May 21 18:54:05 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 21 May 2008 15:54:05 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <48343386.4060700@arin.net> References: <48343386.4060700@arin.net> Message-ID: <4834A80D.7050803@internap.com> Michael, Can you help me understand the rationale for this proposal a bit better? As I understand it, this proposal would "lock in" the size-based distribution of addresses for the remaining ARIN free pool when the IANA free pool is exhausted. That's straightforward enough, but I'm a bit unclear as to the "why". How does locking in such ratios, and reserving space for each group, help ensure a more equitable distribution? Thanks, Scott Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, then the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this 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. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources before > IPv4 Run out > > Author: Michael K. Smith > > Proposal Version: 1 > > Submission Date: 05/20/2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Upon receipt of the last allocation of IPv4 address space to ARIN from > IANA, ARIN will reserve address space within the allocated block for > Organizations within the defined ARIN Organizational Size determinations > (Extra Small, Small, Large, Extra Large) based upon the utilization > percentages for each group gathered from the statistics of the last two > IANA allocations to ARIN. In order to make the allocation percentages > mathematically feasible, the percentages will be rounded to the closest > whole number and, subsequently, the the closest bit boundary for > assignment the maximum allocation size for the Organization size as > defined by ARIN. > > Once the final IANA allocation is received, ARIN will publish the > allocation percentages that will be used for the final allocation to the > PPML and ARIN website with the necessary documentation supporting the > assignment of percentages. > > Rationale: > > Description: > > This policy is designed to allow Organizations of the various defined > sizes to continue to receive address allocations from the last available > space and is slanted towards ensuring that organizations within the > Large, Small and Extra Small groups (and more specifically, the Small > and Extra Small groups) are able to get additional IPv4 space at the end > of the ARIN's ability to allocate such space. Given the statistics > below, it is likely that Extra Large Organizations would get most or all > of the last remaining space because given the amount they have been > allocated to date. This policy would help ensure that other > Organizations had a statistically equal opportunity to receive space as > well. > > > Example: > > Please see http://www.arin.net/statistics/index.html (Note: the > statistics are generated from IP allocations from 2006 and 2007). This > policy would require statistics to be limited to the previous 2 IANA > allocations to ARIN.) > > The present distribution as of May 20th 2008 is: > > Extra Large: 83.11% > Large: 6.75% > Small: 9.00% > Extra Small: 1.14% > > With this example, ARIN would reserve address space in the final IANA > allocation according to those percentages, to the extent that it is > mathematically possible within the existing range. In order to make the > math work, rounding would give us: > > Extra Large: 83% > Large: 7% > Small: 9% > Extra Small: 1% > > Who is affected: > > All ARIN Members will be affected by this policy. I assume that smaller > providers will benefit from having some space available to them beyond > where they would be with an organic allocation model, and the Extra > Large Organizations would experience some pain because, using the model > above, they would be excluded from being allocated 17% of the remaining > space, even if they had all of the necessary justifications for > receiving allocations from within that space. > > Policy Enforcement: > > ARIN staff will have to enforce this policy and ensure that allocations > stay within the published percentages. > > Financial and Liability Implications: > > Financially, there may be additional resources required by ARIN Staff to > allocate resources using this model. These resources might include > application development, staff training and tracking of allocations > based upon the model. > > ARIN may have legal liability should Organizations that were denied > space according to the model decide to contest the legality of the > policy in court. > > Timetable for implementation: Upon receipt of finall IANA allocation > (roughly 2011). > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From mksmith at adhost.com Wed May 21 19:26:19 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 21 May 2008 16:26:19 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <4834A80D.7050803@internap.com> References: <48343386.4060700@arin.net> <4834A80D.7050803@internap.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> Hello Scott: I'm working on a basis assumption that Extra Large organizations request more addresses more frequently than any of the other groups. So, if allocations proceed organically with the last IANA allocation, there is a high likelihood that all of the last allocation will go to the Extra Large organizations alone. So, in an effort to help smaller providers "at the end" we should reserve some space for them so that they can get space, even though they request that space less frequently. If I understand the existing distribution methodology correctly, if there were only a single /20 available at the end, an Extra Large organization could still be allocated that space, even though they had requested a /16. With my proposal, that last /20 would only be available to either a Small or Extra Small Organization depending on how much of the percentage for that group had been allocated already. I used the existing distribution because it seemed a defensible position because it follows historical allocation patterns instead of using some arbitrary assignment of percentages like 75% for Extra Large, 10% for Large, etc. I hope that helps. Please feel free to ask for more clarification. Regards, Mike > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Scott Leibrand > Sent: Wednesday, May 21, 2008 3:54 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 > Resources before IPv4 Run out > > Michael, > > Can you help me understand the rationale for this proposal a bit better? > > As I understand it, this proposal would "lock in" the size-based > distribution of addresses for the remaining ARIN free pool when the IANA > free pool is exhausted. That's straightforward enough, but I'm a bit > unclear as to the "why". How does locking in such ratios, and reserving > space for each group, help ensure a more equitable distribution? > > Thanks, > Scott > > Member Services wrote: > > ARIN received the following policy proposal. In accordance with the ARIN > > Internet Resource Policy Evaluation Process, the proposal is being > > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > > ARIN's website. > > > > The ARIN Advisory Council (AC) will review this proposal at their next > > regularly scheduled meeting. The AC may decide to: > > > > 1. Accept the proposal as written. If the AC accepts the proposal, > > it will be posted as a formal policy proposal to PPML and it will be > > presented at a Public Policy Meeting. > > > > 2. Postpone their decision regarding the proposal until the next > > regularly scheduled AC meeting in order to work with the author. The AC > > will work with the author to clarify, combine or divide the proposal. At > > their following meeting the AC will accept or not accept the proposal. > > > > 3. Not accept the proposal. If the AC does not accept the proposal, > > the AC will explain their decision via the PPML. If a proposal is not > > accepted, then the author may elect to use the petition process to > > advance their proposal. If the author elects not to petition or the > > petition fails, then the proposal will be closed. > > > > The AC will assign shepherds in the near future. ARIN will provide the > > names of the shepherds to the community via the PPML. > > > > In the meantime, the AC invites everyone to comment on this 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. > > > > The ARIN Internet Resource Policy Evaluation Process can be found at: > > http://www.arin.net/policy/irpep.html > > > > Mailing list subscription information can be found at: > > http://www.arin.net/mailing_lists/ > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources before > > IPv4 Run out > > > > Author: Michael K. Smith > > > > Proposal Version: 1 > > > > Submission Date: 05/20/2008 > > > > Proposal type: new > > > > Policy term: permanent > > > > Policy statement: > > > > Upon receipt of the last allocation of IPv4 address space to ARIN from > > IANA, ARIN will reserve address space within the allocated block for > > Organizations within the defined ARIN Organizational Size determinations > > (Extra Small, Small, Large, Extra Large) based upon the utilization > > percentages for each group gathered from the statistics of the last two > > IANA allocations to ARIN. In order to make the allocation percentages > > mathematically feasible, the percentages will be rounded to the closest > > whole number and, subsequently, the the closest bit boundary for > > assignment the maximum allocation size for the Organization size as > > defined by ARIN. > > > > Once the final IANA allocation is received, ARIN will publish the > > allocation percentages that will be used for the final allocation to the > > PPML and ARIN website with the necessary documentation supporting the > > assignment of percentages. > > > > Rationale: > > > > Description: > > > > This policy is designed to allow Organizations of the various defined > > sizes to continue to receive address allocations from the last available > > space and is slanted towards ensuring that organizations within the > > Large, Small and Extra Small groups (and more specifically, the Small > > and Extra Small groups) are able to get additional IPv4 space at the end > > of the ARIN's ability to allocate such space. Given the statistics > > below, it is likely that Extra Large Organizations would get most or all > > of the last remaining space because given the amount they have been > > allocated to date. This policy would help ensure that other > > Organizations had a statistically equal opportunity to receive space as > > well. > > > > > > Example: > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > statistics are generated from IP allocations from 2006 and 2007). This > > policy would require statistics to be limited to the previous 2 IANA > > allocations to ARIN.) > > > > The present distribution as of May 20th 2008 is: > > > > Extra Large: 83.11% > > Large: 6.75% > > Small: 9.00% > > Extra Small: 1.14% > > > > With this example, ARIN would reserve address space in the final IANA > > allocation according to those percentages, to the extent that it is > > mathematically possible within the existing range. In order to make the > > math work, rounding would give us: > > > > Extra Large: 83% > > Large: 7% > > Small: 9% > > Extra Small: 1% > > > > Who is affected: > > > > All ARIN Members will be affected by this policy. I assume that smaller > > providers will benefit from having some space available to them beyond > > where they would be with an organic allocation model, and the Extra > > Large Organizations would experience some pain because, using the model > > above, they would be excluded from being allocated 17% of the remaining > > space, even if they had all of the necessary justifications for > > receiving allocations from within that space. > > > > Policy Enforcement: > > > > ARIN staff will have to enforce this policy and ensure that allocations > > stay within the published percentages. > > > > Financial and Liability Implications: > > > > Financially, there may be additional resources required by ARIN Staff to > > allocate resources using this model. These resources might include > > application development, staff training and tracking of allocations > > based upon the model. > > > > ARIN may have legal liability should Organizations that were denied > > space according to the model decide to contest the legality of the > > policy in court. > > > > Timetable for implementation: Upon receipt of finall IANA allocation > > (roughly 2011). > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN Public > Policy > > Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From steveb at eagle.ca Wed May 21 19:53:16 2008 From: steveb at eagle.ca (Steve Bertrand) Date: Wed, 21 May 2008 19:53:16 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> References: <48343386.4060700@arin.net> <4834A80D.7050803@internap.com> <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> Message-ID: <4834B5EC.3060301@eagle.ca> Michael K. Smith - Adhost wrote: > Hello Scott: > > I'm working on a basis assumption that Extra Large organizations request more addresses more frequently than any of the other groups. So, if allocations proceed organically with the last IANA allocation, there is a high likelihood that all of the last allocation will go to the Extra Large organizations alone. So, in an effort to help smaller providers "at the end" we should reserve some space for them so that they can get space, even though they request that space less frequently. > > If I understand the existing distribution methodology correctly, if there were only a single /20 available at the end, an Extra Large organization could still be allocated that space, even though they had requested a /16. With my proposal, that last /20 would only be available to either a Small or Extra Small Organization depending on how much of the percentage for that group had been allocated already. From how I perceive the language in this proposal, it would mean completely changing or outright over/under stepping the current NRPM. What I mean is, 'well, you qualify 100% with ARIN's number policy, but due to this side size limitation, we have to deny your request'. I believe that this is in complete contrast to the nature of existing policies. The effect I see coming of this would be an exponential requirement for policing near the end due to many loopholes that could be found. For instance, an extra-large organization could quickly roll off numerous very small side shell corporations and fit in nicely with the org size required to take what they want. > I used the existing distribution because it seemed a defensible position because it follows historical allocation patterns instead of using some arbitrary assignment of percentages like 75% for Extra Large, 10% for Large, etc. The thought is there, but the extra effort to govern it is not worth it. History is sometimes a fine path to look at for future events, but in this case, I don't think past trends will be the same going forward. I personally think we will have a drop off of requests of IPv4 address space from micro and small orgs due to rapid deployment of IPv6, and the larger orgs who will have a harder time with IPv6 (due to no immediate requirements to budget it due to having to answer to shareholders and/or lack of interest) will take what they want anyway, any way they can (policy or no policy). Besides, the comment about 'defensible' doesn't stand when you are a /21 holder, and you are trying to compete with a multiple /8 organization for additional space. They will get around you...somehow. If a policy like this was to be considered, then I would prefer a policy that when it comes down to it, the community gets to vote on who gets what, but thats another story. Steve From maier1 at us.ibm.com Wed May 21 20:13:49 2008 From: maier1 at us.ibm.com (Robert Maier) Date: Wed, 21 May 2008 18:13:49 -0600 Subject: [arin-ppml] Robert Maier is currently out of the office until 5/27 Message-ID: I will be out of the office starting 05/21/2008 and will not return until 05/27/2008. Hello, I'll be out of the office Thursday 5/22, returning Tuesday 5/27. If you have an urgent matter, please contact the AOD service center at 877-737-3700. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mathbox.com Thu May 22 00:08:23 2008 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Thu, 22 May 2008 00:08:23 -0400 Subject: [arin-ppml] FW: Policy Proposal: Equitable Distribution of IPv4Resources before IPv4 Run out Message-ID: <0DE02EEAEEB541E5986B615FBC2CFFBB@mathbox.net> Let me see here. 83(approximately) members have 83% of the IP pool. Honestly, I think upper 83% shouldn't get any. They already HAVE 83%. Reserve it for the 2700 members that have the other 17%. Those 83(approximately) members have more wiggle room than the other 2700 members. If those 83(approximately) memebrs do not get any allocations from the last IANA allocation, they will NOT go out of business. On the other hand, a much, much smaller company that is growing, might actually go out of business for lack of an allocation. I am absolutely AGAINST this brain-dead proposal. Michael Thomas > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. > Smith - Adhost > Sent: Wednesday, May 21, 2008 7:26 PM > To: Scott Leibrand; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4Resources before IPv4 Run out > > Hello Scott: > > I'm working on a basis assumption that Extra Large > organizations request more addresses more frequently than any > of the other groups. So, if allocations proceed organically > with the last IANA allocation, there is a high likelihood > that all of the last allocation will go to the Extra Large > organizations alone. So, in an effort to help smaller > providers "at the end" we should reserve some space for them > so that they can get space, even though they request that > space less frequently. > > If I understand the existing distribution methodology > correctly, if there were only a single /20 available at the > end, an Extra Large organization could still be allocated > that space, even though they had requested a /16. With my > proposal, that last /20 would only be available to either a > Small or Extra Small Organization depending on how much of > the percentage for that group had been allocated already. > > I used the existing distribution because it seemed a > defensible position because it follows historical allocation > patterns instead of using some arbitrary assignment of > percentages like 75% for Extra Large, 10% for Large, etc. > > I hope that helps. Please feel free to ask for more clarification. > > Regards, > > Mike > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf > > Of Scott Leibrand > > Sent: Wednesday, May 21, 2008 3:54 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4 > > Resources before IPv4 Run out > > > > Michael, > > > > Can you help me understand the rationale for this proposal > a bit better? > > > > As I understand it, this proposal would "lock in" the size-based > > distribution of addresses for the remaining ARIN free pool > when the IANA > > free pool is exhausted. That's straightforward enough, but > I'm a bit > > unclear as to the "why". How does locking in such ratios, > and reserving > > space for each group, help ensure a more equitable distribution? > > > > Thanks, > > Scott > > > > Member Services wrote: > > > ARIN received the following policy proposal. In > accordance with the ARIN > > > Internet Resource Policy Evaluation Process, the proposal is being > > > posted to the ARIN Public Policy Mailing List (PPML) and > being placed on > > > ARIN's website. > > > > > > The ARIN Advisory Council (AC) will review this proposal > at their next > > > regularly scheduled meeting. The AC may decide to: > > > > > > 1. Accept the proposal as written. If the AC > accepts the proposal, > > > it will be posted as a formal policy proposal to PPML and > it will be > > > presented at a Public Policy Meeting. > > > > > > 2. Postpone their decision regarding the proposal > until the next > > > regularly scheduled AC meeting in order to work with the > author. The AC > > > will work with the author to clarify, combine or divide > the proposal. At > > > their following meeting the AC will accept or not accept > the proposal. > > > > > > 3. Not accept the proposal. If the AC does not > accept the proposal, > > > the AC will explain their decision via the PPML. If a > proposal is not > > > accepted, then the author may elect to use the petition process to > > > advance their proposal. If the author elects not to > petition or the > > > petition fails, then the proposal will be closed. > > > > > > The AC will assign shepherds in the near future. ARIN > will provide the > > > names of the shepherds to the community via the PPML. > > > > > > In the meantime, the AC invites everyone to comment on > this 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. > > > > > > The ARIN Internet Resource Policy Evaluation Process can > be found at: > > > http://www.arin.net/policy/irpep.html > > > > > > Mailing list subscription information can be found at: > > > http://www.arin.net/mailing_lists/ > > > > > > Regards, > > > > > > Member Services > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > ## * ## > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 > Resources before > > > IPv4 Run out > > > > > > Author: Michael K. Smith > > > > > > Proposal Version: 1 > > > > > > Submission Date: 05/20/2008 > > > > > > Proposal type: new > > > > > > Policy term: permanent > > > > > > Policy statement: > > > > > > Upon receipt of the last allocation of IPv4 address space > to ARIN from > > > IANA, ARIN will reserve address space within the > allocated block for > > > Organizations within the defined ARIN Organizational Size > determinations > > > (Extra Small, Small, Large, Extra Large) based upon the > utilization > > > percentages for each group gathered from the statistics > of the last two > > > IANA allocations to ARIN. In order to make the > allocation percentages > > > mathematically feasible, the percentages will be rounded > to the closest > > > whole number and, subsequently, the the closest bit boundary for > > > assignment the maximum allocation size for the > Organization size as > > > defined by ARIN. > > > > > > Once the final IANA allocation is received, ARIN will publish the > > > allocation percentages that will be used for the final > allocation to the > > > PPML and ARIN website with the necessary documentation > supporting the > > > assignment of percentages. > > > > > > Rationale: > > > > > > Description: > > > > > > This policy is designed to allow Organizations of the > various defined > > > sizes to continue to receive address allocations from the > last available > > > space and is slanted towards ensuring that organizations > within the > > > Large, Small and Extra Small groups (and more > specifically, the Small > > > and Extra Small groups) are able to get additional IPv4 > space at the end > > > of the ARIN's ability to allocate such space. Given the > statistics > > > below, it is likely that Extra Large Organizations would > get most or all > > > of the last remaining space because given the amount they > have been > > > allocated to date. This policy would help ensure that other > > > Organizations had a statistically equal opportunity to > receive space as > > > well. > > > > > > > > > Example: > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > statistics are generated from IP allocations from 2006 > and 2007). This > > > policy would require statistics to be limited to the > previous 2 IANA > > > allocations to ARIN.) > > > > > > The present distribution as of May 20th 2008 is: > > > > > > Extra Large: 83.11% > > > Large: 6.75% > > > Small: 9.00% > > > Extra Small: 1.14% > > > > > > With this example, ARIN would reserve address space in > the final IANA > > > allocation according to those percentages, to the extent > that it is > > > mathematically possible within the existing range. In > order to make the > > > math work, rounding would give us: > > > > > > Extra Large: 83% > > > Large: 7% > > > Small: 9% > > > Extra Small: 1% > > > > > > Who is affected: > > > > > > All ARIN Members will be affected by this policy. I > assume that smaller > > > providers will benefit from having some space available > to them beyond > > > where they would be with an organic allocation model, and > the Extra > > > Large Organizations would experience some pain because, > using the model > > > above, they would be excluded from being allocated 17% of > the remaining > > > space, even if they had all of the necessary justifications for > > > receiving allocations from within that space. > > > > > > Policy Enforcement: > > > > > > ARIN staff will have to enforce this policy and ensure > that allocations > > > stay within the published percentages. > > > > > > Financial and Liability Implications: > > > > > > Financially, there may be additional resources required > by ARIN Staff to > > > allocate resources using this model. These resources > might include > > > application development, staff training and tracking of > allocations > > > based upon the model. > > > > > > ARIN may have legal liability should Organizations that > were denied > > > space according to the model decide to contest the legality of the > > > policy in court. > > > > > > Timetable for implementation: Upon receipt of finall > IANA allocation > > > (roughly 2011). > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed > to the ARIN Public > > Policy > > > Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > info at arin.net if you > > experience any issues. > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From Lee.Howard at stanleyassociates.com Thu May 22 10:07:01 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 22 May 2008 10:07:01 -0400 Subject: [arin-ppml] FW: Policy Proposal: Equitable Distribution ofIPv4Resources before IPv4 Run out In-Reply-To: <0DE02EEAEEB541E5986B615FBC2CFFBB@mathbox.net> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB409F7C856@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael > Thomas - Mathbox > Sent: Thursday, May 22, 2008 12:08 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] FW: Policy Proposal: Equitable > Distribution ofIPv4Resources before IPv4 Run out > > Let me see here. 83(approximately) members have 83% of the IP pool. > Honestly, I think upper 83% shouldn't get any. They already HAVE 83%. I don't understand this argument. It's not as if superlarge members are hoarding addresses in a corner to keep smaller players out--they assign them to their customers. Am I mis-assuming the nature of extralarges? If you were to prohibit allocations to extralarge ISPs, all you would be doing is preventing small companies from using the ISP of their choice, effectively forcing them to use a small ISP. There are many good things about small ISPs (I've worked at a couple), but they can't meet all needs. IMHO. Lee From tme at multicasttech.com Thu May 22 10:14:16 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 22 May 2008 10:14:16 -0400 Subject: [arin-ppml] FW: Policy Proposal: Equitable Distribution ofIPv4Resources before IPv4 Run out In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB409F7C856@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB409F7C856@CL-S-EX-1.stanleyassociates.com> Message-ID: On May 22, 2008, at 10:07 AM, Howard, W. Lee wrote: > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael >> Thomas - Mathbox >> Sent: Thursday, May 22, 2008 12:08 AM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] FW: Policy Proposal: Equitable >> Distribution ofIPv4Resources before IPv4 Run out >> >> Let me see here. 83(approximately) members have 83% of the IP pool. >> Honestly, I think upper 83% shouldn't get any. They already HAVE 83%. > > I don't understand this argument. It's not as if superlarge members > are hoarding addresses in a corner to keep smaller players out--they > assign them to their customers. Am I mis-assuming the nature of > extralarges? > > If you were to prohibit allocations to extralarge ISPs, all you would > be doing is preventing small companies from using the ISP of their > choice, effectively forcing them to use a small ISP. There are many > good things about small ISPs (I've worked at a couple), but they > can't meet all needs. It is also not as if large companies cannot set up or make alliances with small companies to get around these sorts of rules. Anyone with any experience with US SIBR contracting will know what I mean. Regards Marshall > > > IMHO. > > Lee > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From kkargel at polartel.com Thu May 22 10:21:14 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 22 May 2008 09:21:14 -0500 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <48343386.4060700@arin.net> References: <48343386.4060700@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10796@mail> I am not in favor of this proposal, if it does any good at all it just forstalls the inevitable for a short time. It comes down to whether it is better to rip the bandaid off or peel is slowly. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Wednesday, May 21, 2008 9:37 AM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out From Ed.Lewis at neustar.biz Thu May 22 10:23:36 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 22 May 2008 10:23:36 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <48343386.4060700@arin.net> References: <48343386.4060700@arin.net> Message-ID: At 10:36 -0400 5/21/08, Member Services wrote: >Policy Proposal Name: Equitable Distribution of IPv4 Resources before >IPv4 Run out I question why a "needs based" allocation ought to be abandoned within ARIN as ARIN's (new) v4 pool is nearing depletion. I don't think it is up to ARIN to play favorites, which is what this policy does. ARIN isn't here to protect the small fry from the big fry or to help the big fry get bigger. Perhaps we ought to reserve the last /8 only for NAT-PT boxes addresses. ;) But that is as far as I'd go. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From Lee.Howard at stanleyassociates.com Thu May 22 10:44:51 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 22 May 2008 10:44:51 -0400 Subject: [arin-ppml] FW: Policy Proposal: Equitable Distribution ofIPv4Resources before IPv4 Run out In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB409F7C8FC@CL-S-EX-1.stanleyassociates.com> > > If you were to prohibit allocations to extralarge ISPs, all > you would > > be doing is preventing small companies from using the ISP of their > > choice, effectively forcing them to use a small ISP. There > are many > > good things about small ISPs (I've worked at a couple), but > they can't > > meet all needs. > > It is also not as if large companies cannot set up or make > alliances with small companies to get around these sorts of > rules. Anyone with any experience with US SIBR contracting > will know what I mean. For those of us who don't have experience with those letters, could you explain what you mean? Do you mean that such alliances are important for the development of the Internet? Thanks, Lee > > Regards > Marshall > > > > > > > > IMHO. > > > > Lee > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact the ARIN Member Services Help Desk at > info at arin.net if > > you experience any issues. > > From mksmith at adhost.com Thu May 22 12:11:21 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 22 May 2008 09:11:21 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: References: <48343386.4060700@arin.net> Message-ID: <17838240D9A5544AAA5FF95F8D52031604098883@ad-exh01.adhost.lan> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Edward Lewis > Sent: Thursday, May 22, 2008 7:24 AM > To: Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 > Resources before IPv4 Run out > > At 10:36 -0400 5/21/08, Member Services wrote: > > >Policy Proposal Name: Equitable Distribution of IPv4 Resources before > >IPv4 Run out > > I question why a "needs based" allocation ought to be abandoned > within ARIN as ARIN's (new) v4 pool is nearing depletion. I don't > think it is up to ARIN to play favorites, which is what this policy > does. ARIN isn't here to protect the small fry from the big fry or > to help the big fry get bigger. > > Perhaps we ought to reserve the last /8 only for NAT-PT boxes > addresses. ;) But that is as far as I'd go. > In one sense the policy is indeed intended to play favorites, but I prefer to view it as a community service in support of smaller organizations, not as a penalization of the larger organizations. One could make the argument that the present pricing structure plays favorites to the Extra Large organizations when you factor a cost per-IP, but that would be an argument for another day. :-) Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From mike at mathbox.com Thu May 22 12:45:27 2008 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Thu, 22 May 2008 12:45:27 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4Resources before IPv4 Run out In-Reply-To: <17838240D9A5544AAA5FF95F8D52031604098883@ad-exh01.adhost.lan> References: <48343386.4060700@arin.net> <17838240D9A5544AAA5FF95F8D52031604098883@ad-exh01.adhost.lan> Message-ID: <63C8294465CB47D9884771E131C9FED7@mathbox.net> Mike > organizations. One could make the argument that the present > pricing structure plays favorites to the Extra Large > organizations when you factor a cost per-IP, but that would > be an argument for another day. :-) Less than a year ago, there were people arguing that IP addresses had no monetary value; that the pricing structure was fair, etc, ad nauseum. Six months later, someone proposes setting up an IP sales clearing house. Irony has its entertainment value. Michael Thomas > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. > Smith - Adhost > Sent: Thursday, May 22, 2008 12:11 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4Resources before IPv4 Run out > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf > > Of Edward Lewis > > Sent: Thursday, May 22, 2008 7:24 AM > > To: Member Services > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4 > > Resources before IPv4 Run out > > > > At 10:36 -0400 5/21/08, Member Services wrote: > > > > >Policy Proposal Name: Equitable Distribution of IPv4 > Resources before > > >IPv4 Run out > > > > I question why a "needs based" allocation ought to be abandoned > > within ARIN as ARIN's (new) v4 pool is nearing depletion. I don't > > think it is up to ARIN to play favorites, which is what this policy > > does. ARIN isn't here to protect the small fry from the big fry or > > to help the big fry get bigger. > > > > Perhaps we ought to reserve the last /8 only for NAT-PT boxes > > addresses. ;) But that is as far as I'd go. > > > > In one sense the policy is indeed intended to play favorites, > but I prefer to view it as a community service in support of > smaller organizations, not as a penalization of the larger > organizations. One could make the argument that the present > pricing structure plays favorites to the Extra Large > organizations when you factor a cost per-IP, but that would > be an argument for another day. :-) > > Regards, > > Mike > From michael.dillon at bt.com Thu May 22 12:51:26 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 22 May 2008 17:51:26 +0100 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4Resources before IPv4 Run out In-Reply-To: <17838240D9A5544AAA5FF95F8D52031604098883@ad-exh01.adhost.lan> References: <48343386.4060700@arin.net> <17838240D9A5544AAA5FF95F8D52031604098883@ad-exh01.adhost.lan> Message-ID: > One could make the argument that the present > pricing structure plays favorites to the Extra Large > organizations when you factor a cost per-IP Not at all. Cost is not a mystical magical mathematical thing. It is real. Does ARIN buy the IP addresses? NO! Does ARIN incur costs to allocate a block of addresses? YES! Are these costs incurred on a per-address basis? No. Are these costs proportional to the number of addresses allocated? No. In fact, the costs involved are rather similar to what accountants call "Cost of Sales" except that no sales are taking place. In the context of what ARIN does, it would be more accurate to call this a "Cost of Services" and I believe that the fee structure does fairly allocate such costs across the different member categories. If someone could show that these costs were not allocated fairly then I would support doubling or tripling the annual fee for the largest member category, but not a fee proportional to the number of IP addresses in the allocated blocks. By the way, the PPML and the AC have no say whatsoever over fees. That is decided by the members so there isn't much point in continuing a discussion on fees and fairness on PPML. --Michael Dillon From tedm at ipinc.net Thu May 22 13:24:49 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 22 May 2008 10:24:49 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <48343386.4060700@arin.net> Message-ID: I support the idea of trying to equalize the last bit of IPv4 address distribution, which this proposal is trying to address. However, I think that while the moral is a Good Thing, there is no practical way to mandate it. If this proposal were to be supported I would ask that the author modify it so that at the least, there would be an automatic expiration to this. The cold hard fact of the matter is that ANY isp or other "small or Very Small" organization that is NOT requesting IP addressing at this time to meet their projected future needs, is likely to get shafted when IPv4 runs out. On the day of IPv4 runout, if an ISP or organization does not have a supply of IPv4 to carry them forward for the immediate future, due to lack of planning, then I daresay they DESERVE to go bankrupt. Do we really want network administrators who aren't paying attention to the gas guage to be driving the Internet into the future? Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Wednesday, May 21, 2008 7:37 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: Equitable Distribution > of IPv4 Resources before IPv4 Run out > > > ARIN received the following policy proposal. In accordance > with the ARIN Internet Resource Policy Evaluation Process, > the proposal is being posted to the ARIN Public Policy > Mailing List (PPML) and being placed on ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at > their next regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts > the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until > the next regularly scheduled AC meeting in order to work with > the author. The AC will work with the author to clarify, > combine or divide the proposal. At their following meeting > the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept > the proposal, the AC will explain their decision via the > PPML. If a proposal is not accepted, then the author may > elect to use the petition process to advance their proposal. > If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will > provide the names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this > 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. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Equitable Distribution of IPv4 > Resources before IPv4 Run out > > Author: Michael K. Smith > > Proposal Version: 1 > > Submission Date: 05/20/2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Upon receipt of the last allocation of IPv4 address space to > ARIN from IANA, ARIN will reserve address space within the > allocated block for Organizations within the defined ARIN > Organizational Size determinations (Extra Small, Small, > Large, Extra Large) based upon the utilization percentages > for each group gathered from the statistics of the last two > IANA allocations to ARIN. In order to make the allocation > percentages mathematically feasible, the percentages will be > rounded to the closest whole number and, subsequently, the > the closest bit boundary for assignment the maximum > allocation size for the Organization size as defined by ARIN. > > Once the final IANA allocation is received, ARIN will publish > the allocation percentages that will be used for the final > allocation to the PPML and ARIN website with the necessary > documentation supporting the assignment of percentages. > > Rationale: > > Description: > > This policy is designed to allow Organizations of the various > defined sizes to continue to receive address allocations from > the last available space and is slanted towards ensuring that > organizations within the Large, Small and Extra Small groups > (and more specifically, the Small and Extra Small groups) are > able to get additional IPv4 space at the end of the ARIN's > ability to allocate such space. Given the statistics below, > it is likely that Extra Large Organizations would get most or > all of the last remaining space because given the amount they > have been allocated to date. This policy would help ensure > that other Organizations had a statistically equal > opportunity to receive space as well. > > > Example: > > Please see http://www.arin.net/statistics/index.html (Note: > the statistics are generated from IP allocations from 2006 > and 2007). This policy would require statistics to be > limited to the previous 2 IANA allocations to ARIN.) > > The present distribution as of May 20th 2008 is: > > Extra Large: 83.11% > Large: 6.75% > Small: 9.00% > Extra Small: 1.14% > > With this example, ARIN would reserve address space in the > final IANA allocation according to those percentages, to the > extent that it is mathematically possible within the existing > range. In order to make the math work, rounding would give us: > > Extra Large: 83% > Large: 7% > Small: 9% > Extra Small: 1% > > Who is affected: > > All ARIN Members will be affected by this policy. I assume > that smaller providers will benefit from having some space > available to them beyond where they would be with an organic > allocation model, and the Extra Large Organizations would > experience some pain because, using the model above, they > would be excluded from being allocated 17% of the remaining > space, even if they had all of the necessary justifications > for receiving allocations from within that space. > > Policy Enforcement: > > ARIN staff will have to enforce this policy and ensure that > allocations stay within the published percentages. > > Financial and Liability Implications: > > Financially, there may be additional resources required by > ARIN Staff to allocate resources using this model. These > resources might include application development, staff > training and tracking of allocations based upon the model. > > ARIN may have legal liability should Organizations that were > denied space according to the model decide to contest the > legality of the policy in court. > > Timetable for implementation: Upon receipt of finall IANA > allocation (roughly 2011). > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From csawyer at cinemark.com Thu May 22 14:03:38 2008 From: csawyer at cinemark.com (Charlie Sawyer) Date: Thu, 22 May 2008 13:03:38 -0500 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4Resources before IPv4 Run out In-Reply-To: References: <48343386.4060700@arin.net> Message-ID: <5AC017EDFC33774E8666D87B614BED41A940DC@txpla01190.usa.cinemark.com> Ip do have value, as any business using the web to generate a revenue stream can tell you. If Arin charged per ip, I doubt we would be running out of IP' addresses any time in the near future. You would see a lot of IP addresses being returned that were not in use, at the very least. Supply and demand with free market can solve many issues. Thanks, Charlie Sawyer -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Thursday, May 22, 2008 12:25 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4Resources before IPv4 Run out I support the idea of trying to equalize the last bit of IPv4 address distribution, which this proposal is trying to address. However, I think that while the moral is a Good Thing, there is no practical way to mandate it. If this proposal were to be supported I would ask that the author modify it so that at the least, there would be an automatic expiration to this. The cold hard fact of the matter is that ANY isp or other "small or Very Small" organization that is NOT requesting IP addressing at this time to meet their projected future needs, is likely to get shafted when IPv4 runs out. On the day of IPv4 runout, if an ISP or organization does not have a supply of IPv4 to carry them forward for the immediate future, due to lack of planning, then I daresay they DESERVE to go bankrupt. Do we really want network administrators who aren't paying attention to the gas guage to be driving the Internet into the future? Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Wednesday, May 21, 2008 7:37 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: Equitable Distribution > of IPv4 Resources before IPv4 Run out > > > ARIN received the following policy proposal. In accordance > with the ARIN Internet Resource Policy Evaluation Process, > the proposal is being posted to the ARIN Public Policy > Mailing List (PPML) and being placed on ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at > their next regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts > the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until > the next regularly scheduled AC meeting in order to work with > the author. The AC will work with the author to clarify, > combine or divide the proposal. At their following meeting > the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept > the proposal, the AC will explain their decision via the > PPML. If a proposal is not accepted, then the author may > elect to use the petition process to advance their proposal. > If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will > provide the names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this > 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. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Equitable Distribution of IPv4 > Resources before IPv4 Run out > > Author: Michael K. Smith > > Proposal Version: 1 > > Submission Date: 05/20/2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Upon receipt of the last allocation of IPv4 address space to > ARIN from IANA, ARIN will reserve address space within the > allocated block for Organizations within the defined ARIN > Organizational Size determinations (Extra Small, Small, > Large, Extra Large) based upon the utilization percentages > for each group gathered from the statistics of the last two > IANA allocations to ARIN. In order to make the allocation > percentages mathematically feasible, the percentages will be > rounded to the closest whole number and, subsequently, the > the closest bit boundary for assignment the maximum > allocation size for the Organization size as defined by ARIN. > > Once the final IANA allocation is received, ARIN will publish > the allocation percentages that will be used for the final > allocation to the PPML and ARIN website with the necessary > documentation supporting the assignment of percentages. > > Rationale: > > Description: > > This policy is designed to allow Organizations of the various > defined sizes to continue to receive address allocations from > the last available space and is slanted towards ensuring that > organizations within the Large, Small and Extra Small groups > (and more specifically, the Small and Extra Small groups) are > able to get additional IPv4 space at the end of the ARIN's > ability to allocate such space. Given the statistics below, > it is likely that Extra Large Organizations would get most or > all of the last remaining space because given the amount they > have been allocated to date. This policy would help ensure > that other Organizations had a statistically equal > opportunity to receive space as well. > > > Example: > > Please see http://www.arin.net/statistics/index.html (Note: > the statistics are generated from IP allocations from 2006 > and 2007). This policy would require statistics to be > limited to the previous 2 IANA allocations to ARIN.) > > The present distribution as of May 20th 2008 is: > > Extra Large: 83.11% > Large: 6.75% > Small: 9.00% > Extra Small: 1.14% > > With this example, ARIN would reserve address space in the > final IANA allocation according to those percentages, to the > extent that it is mathematically possible within the existing > range. In order to make the math work, rounding would give us: > > Extra Large: 83% > Large: 7% > Small: 9% > Extra Small: 1% > > Who is affected: > > All ARIN Members will be affected by this policy. I assume > that smaller providers will benefit from having some space > available to them beyond where they would be with an organic > allocation model, and the Extra Large Organizations would > experience some pain because, using the model above, they > would be excluded from being allocated 17% of the remaining > space, even if they had all of the necessary justifications > for receiving allocations from within that space. > > Policy Enforcement: > > ARIN staff will have to enforce this policy and ensure that > allocations stay within the published percentages. > > Financial and Liability Implications: > > Financially, there may be additional resources required by > ARIN Staff to allocate resources using this model. These > resources might include application development, staff > training and tracking of allocations based upon the model. > > ARIN may have legal liability should Organizations that were > denied space according to the model decide to contest the > legality of the policy in court. > > Timetable for implementation: Upon receipt of finall IANA > allocation (roughly 2011). > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From tedm at ipinc.net Thu May 22 14:32:12 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 22 May 2008 11:32:12 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution ofIPv4Resources before IPv4 Run out In-Reply-To: <5AC017EDFC33774E8666D87B614BED41A940DC@txpla01190.usa.cinemark.com> Message-ID: Hey, whatever your smoking, I want some! ARIN -does- charge per IP address. I may have imbibed a number of hallucinogenic substances over the years but the bill we get from them every year is most definitely NOT a figment of my imagination! Or were you under the impression that ARIN was funded by Tinker Bell and friends? In case you were, here is the ARIN fee schedule: http://www.arin.net/billing/fee_schedule.html Fees per IP address: X-small: 61 cents/year Small: 28 cents/year Medium: 6 cents/year Large: 3 cents/year and so forth. The fact of the matter is that on a per-IP basis, the smaller allocations cost everyone on the Internet more money per customer, because we have to carry more route entries for the same number of customers, so I am perfectly contented with the "smaller allocation tax" of more cents per IP per year If you go to Costco the giant bundle of toilet paper also costs less per roll. That's just how things work in life. But the idea that ARIN isn't charging money for IP's is rediculous. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > Sent: Thursday, May 22, 2008 11:04 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution ofIPv4Resources before IPv4 Run out > > > Ip do have value, as any business using the web to generate a > revenue stream can tell you. If Arin charged per ip, I doubt > we would be > running out of IP' addresses any time in the near future. You would > see a lot of IP addresses being returned that were not in > use, at the very least. > > Supply and demand with free market can solve many issues. > > > Thanks, > Charlie Sawyer > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > Sent: Thursday, May 22, 2008 12:25 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4Resources before IPv4 Run out > > > I support the idea of trying to equalize the last bit of > IPv4 address distribution, which this proposal is trying > to address. > > However, I think that while the moral is a Good Thing, there > is no practical way to mandate it. > > If this proposal were to be supported I would ask that the > author modify it so that at the least, there would be an > automatic expiration to this. > > The cold hard fact of the matter is that ANY isp or other > "small or Very Small" organization that is NOT requesting > IP addressing at this time to meet their projected future > needs, is likely to get shafted when IPv4 runs out. > > On the day of IPv4 runout, if an ISP or organization does > not have a supply of IPv4 to carry them forward for the > immediate future, due to lack of planning, then I daresay > they DESERVE to go bankrupt. > > Do we really want network administrators who aren't paying > attention to the gas guage to be driving the Internet into the future? > > Ted > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > Sent: Wednesday, May 21, 2008 7:37 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution > > of IPv4 Resources before IPv4 Run out > > > > > > ARIN received the following policy proposal. In accordance > > with the ARIN Internet Resource Policy Evaluation Process, > > the proposal is being posted to the ARIN Public Policy > > Mailing List (PPML) and being placed on ARIN's website. > > > > The ARIN Advisory Council (AC) will review this proposal at > > their next regularly scheduled meeting. The AC may decide to: > > > > 1. Accept the proposal as written. If the AC accepts > > the proposal, it will be posted as a formal policy proposal > > to PPML and it will be presented at a Public Policy Meeting. > > > > 2. Postpone their decision regarding the proposal until > > the next regularly scheduled AC meeting in order to work with > > the author. The AC will work with the author to clarify, > > combine or divide the proposal. At their following meeting > > the AC will accept or not accept the proposal. > > > > 3. Not accept the proposal. If the AC does not accept > > the proposal, the AC will explain their decision via the > > PPML. If a proposal is not accepted, then the author may > > elect to use the petition process to advance their proposal. > > If the author elects not to petition or the petition fails, > > then the proposal will be closed. > > > > The AC will assign shepherds in the near future. ARIN will > > provide the names of the shepherds to the community via the PPML. > > > > In the meantime, the AC invites everyone to comment on this > > 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. > > > > The ARIN Internet Resource Policy Evaluation Process can be > > found at: http://www.arin.net/policy/irpep.html > > > > Mailing list subscription information can be found at: > > http://www.arin.net/mailing_lists/ > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 > > Resources before IPv4 Run out > > > > Author: Michael K. Smith > > > > Proposal Version: 1 > > > > Submission Date: 05/20/2008 > > > > Proposal type: new > > > > Policy term: permanent > > > > Policy statement: > > > > Upon receipt of the last allocation of IPv4 address space to > > ARIN from IANA, ARIN will reserve address space within the > > allocated block for Organizations within the defined ARIN > > Organizational Size determinations (Extra Small, Small, > > Large, Extra Large) based upon the utilization percentages > > for each group gathered from the statistics of the last two > > IANA allocations to ARIN. In order to make the allocation > > percentages mathematically feasible, the percentages will be > > rounded to the closest whole number and, subsequently, the > > the closest bit boundary for assignment the maximum > > allocation size for the Organization size as defined by ARIN. > > > > Once the final IANA allocation is received, ARIN will publish > > the allocation percentages that will be used for the final > > allocation to the PPML and ARIN website with the necessary > > documentation supporting the assignment of percentages. > > > > Rationale: > > > > Description: > > > > This policy is designed to allow Organizations of the various > > defined sizes to continue to receive address allocations from > > the last available space and is slanted towards ensuring that > > organizations within the Large, Small and Extra Small groups > > (and more specifically, the Small and Extra Small groups) are > > able to get additional IPv4 space at the end of the ARIN's > > ability to allocate such space. Given the statistics below, > > it is likely that Extra Large Organizations would get most or > > all of the last remaining space because given the amount they > > have been allocated to date. This policy would help ensure > > that other Organizations had a statistically equal > > opportunity to receive space as well. > > > > > > Example: > > > > Please see http://www.arin.net/statistics/index.html (Note: > > the statistics are generated from IP allocations from 2006 > > and 2007). This policy would require statistics to be > > limited to the previous 2 IANA allocations to ARIN.) > > > > The present distribution as of May 20th 2008 is: > > > > Extra Large: 83.11% > > Large: 6.75% > > Small: 9.00% > > Extra Small: 1.14% > > > > With this example, ARIN would reserve address space in the > > final IANA allocation according to those percentages, to the > > extent that it is mathematically possible within the existing > > range. In order to make the math work, rounding would give us: > > > > Extra Large: 83% > > Large: 7% > > Small: 9% > > Extra Small: 1% > > > > Who is affected: > > > > All ARIN Members will be affected by this policy. I assume > > that smaller providers will benefit from having some space > > available to them beyond where they would be with an organic > > allocation model, and the Extra Large Organizations would > > experience some pain because, using the model above, they > > would be excluded from being allocated 17% of the remaining > > space, even if they had all of the necessary justifications > > for receiving allocations from within that space. > > > > Policy Enforcement: > > > > ARIN staff will have to enforce this policy and ensure that > > allocations stay within the published percentages. > > > > Financial and Liability Implications: > > > > Financially, there may be additional resources required by > > ARIN Staff to allocate resources using this model. These > > resources might include application development, staff > > training and tracking of allocations based upon the model. > > > > ARIN may have legal liability should Organizations that were > > denied space according to the model decide to contest the > > legality of the policy in court. > > > > Timetable for implementation: Upon receipt of finall IANA > > allocation (roughly 2011). > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From Lee.Howard at stanleyassociates.com Thu May 22 15:17:02 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 22 May 2008 15:17:02 -0400 Subject: [arin-ppml] Policy Proposal: Equitable DistributionofIPv4Resources before IPv4 Run out In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB409F7CD5C@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > Sent: Thursday, May 22, 2008 2:32 PM > To: 'Charlie Sawyer'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable > DistributionofIPv4Resources before IPv4 Run out > > > Hey, whatever your smoking, I want some! > > ARIN -does- charge per IP address. I may have imbibed a No, ARIN charges for registration services. We have considered many different pricing schemes, but the fundamental rationale that the members have given us is to cover costs. > In case you were, here is the ARIN fee schedule: > > http://www.arin.net/billing/fee_schedule.html > > Fees per IP address: The fees are not set per IP address. The fees are based on size categories, which are rough groupings based on total allocation block size. Annual fees are different for ISPs and end user organizations. The membership and the board have discussed different options over the years, but none has been clearly superior (to a consensus of the memebrs). Lee Howard, Treasurer From mike at mathbox.com Thu May 22 15:22:25 2008 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Thu, 22 May 2008 15:22:25 -0400 Subject: [arin-ppml] Policy Proposal: Equitable DistributionofIPv4Resources before IPv4 Run out In-Reply-To: References: <5AC017EDFC33774E8666D87B614BED41A940DC@txpla01190.usa.cinemark.com> Message-ID: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net> Ted, At the risk of receiving the wrath of the PPML Gods... > X-small: 61 cents/year X-Large fee is up to a /14. Anything over a /14 is no charge. So, you cannot apply a single divisor that applies to all X-Large. The /8 that they may also have is FREE. Most X-Large pay less than $.01 per IP. > The fact of the matter is that on a per-IP basis, the smaller > allocations cost everyone on the Internet more money per customer, > because we have to carry more route entries for the same number It is a two-way street... > of customers, so I am perfectly contented with the "smaller allocation > tax" of more cents per IP per year Exactly how much of that "tax-the-poor" does your company collect? Other than providing a barrier to competition, how does it benefit your company? Michael Thomas > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > Sent: Thursday, May 22, 2008 2:32 PM > To: 'Charlie Sawyer'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable > DistributionofIPv4Resources before IPv4 Run out > > > Hey, whatever your smoking, I want some! > > ARIN -does- charge per IP address. I may have imbibed > a number of hallucinogenic substances over the years but > the bill we get from them every year is most definitely > NOT a figment of my imagination! > > Or were you under the impression that ARIN was funded by > Tinker Bell and friends? > > In case you were, here is the ARIN fee schedule: > > http://www.arin.net/billing/fee_schedule.html > > Fees per IP address: > > X-small: 61 cents/year > Small: 28 cents/year > Medium: 6 cents/year > Large: 3 cents/year > > and so forth. > > The fact of the matter is that on a per-IP basis, the smaller > allocations cost everyone on the Internet more money per customer, > because we have to carry more route entries for the same number > of customers, so I am perfectly contented with the "smaller allocation > tax" of more cents per IP per year > > If you go to Costco the giant bundle of toilet paper also costs > less per roll. That's just how things work in life. > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > Ted > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > Sent: Thursday, May 22, 2008 11:04 AM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > Distribution ofIPv4Resources before IPv4 Run out > > > > > > Ip do have value, as any business using the web to generate a > > revenue stream can tell you. If Arin charged per ip, I doubt > > we would be > > running out of IP' addresses any time in the near future. > You would > > see a lot of IP addresses being returned that were not in > > use, at the very least. > > > > Supply and demand with free market can solve many issues. > > > > > > Thanks, > > Charlie Sawyer > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 12:25 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > Distribution of IPv4Resources before IPv4 Run out > > > > > > I support the idea of trying to equalize the last bit of > > IPv4 address distribution, which this proposal is trying > > to address. > > > > However, I think that while the moral is a Good Thing, there > > is no practical way to mandate it. > > > > If this proposal were to be supported I would ask that the > > author modify it so that at the least, there would be an > > automatic expiration to this. > > > > The cold hard fact of the matter is that ANY isp or other > > "small or Very Small" organization that is NOT requesting > > IP addressing at this time to meet their projected future > > needs, is likely to get shafted when IPv4 runs out. > > > > On the day of IPv4 runout, if an ISP or organization does > > not have a supply of IPv4 to carry them forward for the > > immediate future, due to lack of planning, then I daresay > > they DESERVE to go bankrupt. > > > > Do we really want network administrators who aren't paying > > attention to the gas guage to be driving the Internet into > the future? > > > > Ted > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > To: arin-ppml at arin.net > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution > > > of IPv4 Resources before IPv4 Run out > > > > > > > > > ARIN received the following policy proposal. In accordance > > > with the ARIN Internet Resource Policy Evaluation Process, > > > the proposal is being posted to the ARIN Public Policy > > > Mailing List (PPML) and being placed on ARIN's website. > > > > > > The ARIN Advisory Council (AC) will review this proposal at > > > their next regularly scheduled meeting. The AC may decide to: > > > > > > 1. Accept the proposal as written. If the AC accepts > > > the proposal, it will be posted as a formal policy proposal > > > to PPML and it will be presented at a Public Policy Meeting. > > > > > > 2. Postpone their decision regarding the proposal until > > > the next regularly scheduled AC meeting in order to work with > > > the author. The AC will work with the author to clarify, > > > combine or divide the proposal. At their following meeting > > > the AC will accept or not accept the proposal. > > > > > > 3. Not accept the proposal. If the AC does not accept > > > the proposal, the AC will explain their decision via the > > > PPML. If a proposal is not accepted, then the author may > > > elect to use the petition process to advance their proposal. > > > If the author elects not to petition or the petition fails, > > > then the proposal will be closed. > > > > > > The AC will assign shepherds in the near future. ARIN will > > > provide the names of the shepherds to the community via the PPML. > > > > > > In the meantime, the AC invites everyone to comment on this > > > 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. > > > > > > The ARIN Internet Resource Policy Evaluation Process can be > > > found at: http://www.arin.net/policy/irpep.html > > > > > > Mailing list subscription information can be found at: > > > http://www.arin.net/mailing_lists/ > > > > > > Regards, > > > > > > Member Services > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > ## * ## > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 > > > Resources before IPv4 Run out > > > > > > Author: Michael K. Smith > > > > > > Proposal Version: 1 > > > > > > Submission Date: 05/20/2008 > > > > > > Proposal type: new > > > > > > Policy term: permanent > > > > > > Policy statement: > > > > > > Upon receipt of the last allocation of IPv4 address space to > > > ARIN from IANA, ARIN will reserve address space within the > > > allocated block for Organizations within the defined ARIN > > > Organizational Size determinations (Extra Small, Small, > > > Large, Extra Large) based upon the utilization percentages > > > for each group gathered from the statistics of the last two > > > IANA allocations to ARIN. In order to make the allocation > > > percentages mathematically feasible, the percentages will be > > > rounded to the closest whole number and, subsequently, the > > > the closest bit boundary for assignment the maximum > > > allocation size for the Organization size as defined by ARIN. > > > > > > Once the final IANA allocation is received, ARIN will publish > > > the allocation percentages that will be used for the final > > > allocation to the PPML and ARIN website with the necessary > > > documentation supporting the assignment of percentages. > > > > > > Rationale: > > > > > > Description: > > > > > > This policy is designed to allow Organizations of the various > > > defined sizes to continue to receive address allocations from > > > the last available space and is slanted towards ensuring that > > > organizations within the Large, Small and Extra Small groups > > > (and more specifically, the Small and Extra Small groups) are > > > able to get additional IPv4 space at the end of the ARIN's > > > ability to allocate such space. Given the statistics below, > > > it is likely that Extra Large Organizations would get most or > > > all of the last remaining space because given the amount they > > > have been allocated to date. This policy would help ensure > > > that other Organizations had a statistically equal > > > opportunity to receive space as well. > > > > > > > > > Example: > > > > > > Please see http://www.arin.net/statistics/index.html (Note: > > > the statistics are generated from IP allocations from 2006 > > > and 2007). This policy would require statistics to be > > > limited to the previous 2 IANA allocations to ARIN.) > > > > > > The present distribution as of May 20th 2008 is: > > > > > > Extra Large: 83.11% > > > Large: 6.75% > > > Small: 9.00% > > > Extra Small: 1.14% > > > > > > With this example, ARIN would reserve address space in the > > > final IANA allocation according to those percentages, to the > > > extent that it is mathematically possible within the existing > > > range. In order to make the math work, rounding would give us: > > > > > > Extra Large: 83% > > > Large: 7% > > > Small: 9% > > > Extra Small: 1% > > > > > > Who is affected: > > > > > > All ARIN Members will be affected by this policy. I assume > > > that smaller providers will benefit from having some space > > > available to them beyond where they would be with an organic > > > allocation model, and the Extra Large Organizations would > > > experience some pain because, using the model above, they > > > would be excluded from being allocated 17% of the remaining > > > space, even if they had all of the necessary justifications > > > for receiving allocations from within that space. > > > > > > Policy Enforcement: > > > > > > ARIN staff will have to enforce this policy and ensure that > > > allocations stay within the published percentages. > > > > > > Financial and Liability Implications: > > > > > > Financially, there may be additional resources required by > > > ARIN Staff to allocate resources using this model. These > > > resources might include application development, staff > > > training and tracking of allocations based upon the model. > > > > > > ARIN may have legal liability should Organizations that were > > > denied space according to the model decide to contest the > > > legality of the policy in court. > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > allocation (roughly 2011). > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > > From tedm at ipinc.net Thu May 22 15:58:02 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 22 May 2008 12:58:02 -0700 Subject: [arin-ppml] Policy Proposal: EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB409F7CD5C@CL-S-EX-1.stanleyassociates.com> Message-ID: <72D36788307E4A1E993BBBC4A9FE0F9D@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee > Sent: Thursday, May 22, 2008 12:17 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 2:32 PM > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > DistributionofIPv4Resources before IPv4 Run out > > > > > > Hey, whatever your smoking, I want some! > > > > ARIN -does- charge per IP address. I may have imbibed a > > No, ARIN charges for registration services. We have > considered many different pricing schemes, but the > fundamental rationale that the members have given us is to > cover costs. > Legally, ARIN cannot say they are charging for IP addresses because we are trying to maintain the legal definition that IP addresses are not property, for many reasons that I fully support. However, from a non-legal, man-in-the-street perspective, there is no difference between saying your charging for registration services and saying your charging for IP addresses on a per-IP basis. Your still charging money, we are still paying money. We get more IP from you we pay more money. The poster's claim that "if ARIN charged on a per-IP basis there would be a lot of free IPv4" is thus bogus from a man-in-the street perspective, because effectively, ARIN -is- doing that, yet we do not have plentiful IPv4. > > In case you were, here is the ARIN fee schedule: > > > > http://www.arin.net/billing/fee_schedule.html > > > > Fees per IP address: > > The fees are not set per IP address. The fees are based on > size categories, which are rough groupings based on total > allocation block size. Annual fees are different for ISPs > and end user organizations. > Once more, it makes no difference. When you buy gasoline you buy it in the per-gallon basis, not the per pint basis. Yet, your lawnmower takes only a pint of gas in it's tank, your model airplane only takes a teaspoon of gas, cleaning grease with a rag off your driveway only takes a few drops of gas, etc. etc. Each of those actions consumes gas, which can be measured by the number of pennies of gas is consumed, or by the rougher groupings of the number of dollars of gas is consumed. Ted From tedm at ipinc.net Thu May 22 16:41:30 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 22 May 2008 13:41:30 -0700 Subject: [arin-ppml] Policy Proposal: EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net> Message-ID: <78104401AB7C4B22AF163FDB02062391@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael > Thomas - Mathbox > Sent: Thursday, May 22, 2008 12:22 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: > EquitableDistributionofIPv4Resources before IPv4 Run out > > > Ted, > > At the risk of receiving the wrath of the PPML Gods... > > > X-small: 61 cents/year > > X-Large fee is up to a /14. Anything over a /14 is no charge. > So, you cannot apply a single divisor that applies to all > X-Large. The /8 that they may also have is FREE. Most X-Large > pay less than $.01 per IP. > "...may also have is FREE..." is a reference to legacy allocations and I was not talking about that, those are a separate issue. As for the penny an IP address the X-large pays, sure on the surface that seems unfair. But, I will point out that precisely because they are X-large, and have so many IP's already, that in a time of IPv4 runout, they are going to be under intense pressure to both move to IPv6, and also to justify why they have so much IPv4 tied up. The small low-growth organizations who have maybe a /18 tied up, and who are experiencing maybe a 2% per year real growth in customer count, those folks aren't going to suffer in IPv4 runout time. They will be paying their bills, keeping people employed, keeping their customers happy, basically being good citizens. They will be able to sit back and weather the storm, and because they have so little IPv4 tied up as compared to the large holders, nobody is going to come banging on their door demanding they prove justification for their holdings, because even if what they have has a lot of unused numbers, the amount of unused numbering they have is so small it won't help any of the larger well-financed consumers of IP addressing for more than a few days of growth. The political and economic realities are that the X-larges are going to bear the brunt of the costs of switchover to IPv6 - and they will also suffer the largest customer losses, as they tell customers that they can't support IPv4, those customers who don't want to switch (think - all of them) will be going to the smaller providers. And when the large guys have ended up funding all the R&D for the production deployment of IPv6, by then the small guys will have a literal wealth of gear and deployment strategies to pick and choose from, as well as be able to know all the pitfalls, AND even better, since they really will be the last to covert over, their customers will not be able to carry out the threat of "quitting service and finding an ISP that will sell us IPv4" since there won't BE any ISP's left that will sell IPv4. > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number > > It is a two-way street... > > > of customers, so I am perfectly contented with the "smaller > allocation > > tax" of more cents per IP per year > > Exactly how much of that "tax-the-poor" does your company > collect? Other than providing a barrier to competition, how > does it benefit your company? > Naturally, our pricing has to be set according to what the other guy has his pricing set to - that's determined by competition. But, because we are smaller, we have much more flexibility in reducing our internal costs than the large guy does. So we pay more for numbering, but we can do things like using PC's running Quagga for BGP routers instead of Junipers, and the savings more than make up for the IP costs. (I'm not saying that we currently do this, but we have done so in the past - and the reliability is no worse than the commercial routers) It all has a way of working out in the end. Ted > Michael Thomas > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 2:32 PM > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > DistributionofIPv4Resources before IPv4 Run out > > > > > > Hey, whatever your smoking, I want some! > > > > ARIN -does- charge per IP address. I may have imbibed > > a number of hallucinogenic substances over the years but > > the bill we get from them every year is most definitely > > NOT a figment of my imagination! > > > > Or were you under the impression that ARIN was funded by > Tinker Bell > > and friends? > > > > In case you were, here is the ARIN fee schedule: > > > > http://www.arin.net/billing/fee_schedule.html > > > > Fees per IP address: > > > > X-small: 61 cents/year > > Small: 28 cents/year > > Medium: 6 cents/year > > Large: 3 cents/year > > > > and so forth. > > > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number of > > customers, so I am perfectly contented with the "smaller allocation > > tax" of more cents per IP per year > > > > If you go to Costco the giant bundle of toilet paper also > costs less > > per roll. That's just how things work in life. > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > Ted > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > Sent: Thursday, May 22, 2008 11:04 AM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > Distribution ofIPv4Resources before IPv4 Run out > > > > > > > > > Ip do have value, as any business using the web to generate a > > > revenue stream can tell you. If Arin charged per ip, I doubt > > > we would be > > > running out of IP' addresses any time in the near future. > > You would > > > see a lot of IP addresses being returned that were not in > > > use, at the very least. > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > Thanks, > > > Charlie Sawyer > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 12:25 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > Distribution of IPv4Resources before IPv4 Run out > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > address distribution, which this proposal is trying to address. > > > > > > However, I think that while the moral is a Good Thing, > there is no > > > practical way to mandate it. > > > > > > If this proposal were to be supported I would ask that the > > > author modify it so that at the least, there would be an > > > automatic expiration to this. > > > > > > The cold hard fact of the matter is that ANY isp or other > > > "small or Very Small" organization that is NOT requesting > > > IP addressing at this time to meet their projected future > > > needs, is likely to get shafted when IPv4 runs out. > > > > > > On the day of IPv4 runout, if an ISP or organization does > not have a > > > supply of IPv4 to carry them forward for the immediate > future, due > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > Do we really want network administrators who aren't paying > > > attention to the gas guage to be driving the Internet into > > the future? > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > To: arin-ppml at arin.net > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution > > > > of IPv4 Resources before IPv4 Run out > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > the ARIN Internet Resource Policy Evaluation Process, > the proposal > > > > is being posted to the ARIN Public Policy Mailing List > (PPML) and > > > > being placed on ARIN's website. > > > > > > > > The ARIN Advisory Council (AC) will review this > proposal at their > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > 2. Postpone their decision regarding the proposal > until the > > > > next regularly scheduled AC meeting in order to work with the > > > > author. The AC will work with the author to clarify, combine or > > > > divide the proposal. At their following meeting the AC > will accept > > > > or not accept the proposal. > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > proposal, the AC will explain their decision via the PPML. If a > > > > proposal is not accepted, then the author may elect to use the > > > > petition process to advance their proposal. If the > author elects > > > > not to petition or the petition fails, then the > proposal will be > > > > closed. > > > > > > > > The AC will assign shepherds in the near future. ARIN > will provide > > > > the names of the shepherds to the community via the PPML. > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > 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. > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > can be found > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > Mailing list subscription information can be found at: > > > > http://www.arin.net/mailing_lists/ > > > > > > > > Regards, > > > > > > > > Member Services > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > ## * ## > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > before IPv4 Run out > > > > > > > > Author: Michael K. Smith > > > > > > > > Proposal Version: 1 > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > Proposal type: new > > > > > > > > Policy term: permanent > > > > > > > > Policy statement: > > > > > > > > Upon receipt of the last allocation of IPv4 address > space to ARIN > > > > from IANA, ARIN will reserve address space within the allocated > > > > block for Organizations within the defined ARIN Organizational > > > > Size determinations (Extra Small, Small, Large, Extra > Large) based > > > > upon the utilization percentages for each group > gathered from the > > > > statistics of the last two IANA allocations to ARIN. > In order to > > > > make the allocation percentages mathematically feasible, the > > > > percentages will be rounded to the closest whole number and, > > > > subsequently, the the closest bit boundary for assignment the > > > > maximum allocation size for the Organization size as defined by > > > > ARIN. > > > > > > > > Once the final IANA allocation is received, ARIN will > publish the > > > > allocation percentages that will be used for the final > allocation > > > > to the PPML and ARIN website with the necessary documentation > > > > supporting the assignment of percentages. > > > > > > > > Rationale: > > > > > > > > Description: > > > > > > > > This policy is designed to allow Organizations of the various > > > > defined sizes to continue to receive address > allocations from the > > > > last available space and is slanted towards ensuring that > > > > organizations within the Large, Small and Extra Small > groups (and > > > > more specifically, the Small and Extra Small groups) > are able to > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > allocate such space. Given the statistics below, it is likely > > > > that Extra Large Organizations would get most or all of > the last > > > > remaining space because given the amount they have been > allocated > > > > to date. This policy would help ensure that other > Organizations > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > Example: > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > statistics are generated from IP allocations from 2006 > and 2007). > > > > This policy would require statistics to be limited to > the previous > > > > 2 IANA allocations to ARIN.) > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > Extra Large: 83.11% > > > > Large: 6.75% > > > > Small: 9.00% > > > > Extra Small: 1.14% > > > > > > > > With this example, ARIN would reserve address space in > the final > > > > IANA allocation according to those percentages, to the > extent that > > > > it is mathematically possible within the existing > range. In order > > > > to make the math work, rounding would give us: > > > > > > > > Extra Large: 83% > > > > Large: 7% > > > > Small: 9% > > > > Extra Small: 1% > > > > > > > > Who is affected: > > > > > > > > All ARIN Members will be affected by this policy. I > assume that > > > > smaller providers will benefit from having some space > available to > > > > them beyond where they would be with an organic > allocation model, > > > > and the Extra Large Organizations would experience some pain > > > > because, using the model above, they would be excluded > from being > > > > allocated 17% of the remaining space, even if they had > all of the > > > > necessary justifications for receiving allocations from within > > > > that space. > > > > > > > > Policy Enforcement: > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > allocations stay within the published percentages. > > > > > > > > Financial and Liability Implications: > > > > > > > > Financially, there may be additional resources required by ARIN > > > > Staff to allocate resources using this model. These resources > > > > might include application development, staff training > and tracking > > > > of allocations based upon the model. > > > > > > > > ARIN may have legal liability should Organizations that were > > > > denied space according to the model decide to contest > the legality > > > > of the policy in court. > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > allocation (roughly 2011). > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are > subscribed to the > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe > > > > or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From ppml at rs.seastrom.com Thu May 22 18:43:19 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Thu, 22 May 2008 18:43:19 -0400 Subject: [arin-ppml] Policy Proposal: Equitable DistributionofIPv4Resources before IPv4 Run out In-Reply-To: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net> (Michael Thomas's message of "Thu, 22 May 2008 15:22:25 -0400") References: <5AC017EDFC33774E8666D87B614BED41A940DC@txpla01190.usa.cinemark.com> <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net> Message-ID: <861w3uc648.fsf@seastrom.com> "Michael Thomas - Mathbox" writes: > X-Large fee is up to a /14. Anything over a /14 is no charge. So, you cannot > apply a single divisor that applies to all X-Large. The /8 that they may > also have is FREE. Not sure where you got that idea. Anything up to and including a /14 is Large, $9k/year. Over a /14 is X-Large, $18k/year. http://www.arin.net/billing/fee_schedule.html#ipv4_alloc > Most X-Large pay less than $.01 per IP. X-Small pays $1.22 > N > $0.30 per addr per year Small pays $0.54 > N > $0.27 per addr per year Medium pays $0.54 > N > $0.06 per addr per year Large pays $0.13 > N > $0.03 per addr per year X-Large pays $0.06 > N > $verysmall per addr per year So what? The big organizations also put substantially less burden on ARIN's analysts because they know what they are doing and interact well with ARIN's processes. Based on cost of actually providing the service, charging the X-Small and Small organizations more is almost certainly warranted. By the way, you might want to load this web page for musical accompaniment: http://www.christianwebresources.co.uk/midi/files/174.mid while you're rearranging the deck chairs on the Titanic. The IPv4 pricing structure is in the category of "things nobody will care about in a few years". ---Rob (on the AC, speaking for self) From Daniel_Alexander at Cable.Comcast.com Thu May 22 19:12:55 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 22 May 2008 19:12:55 -0400 Subject: [arin-ppml] Policy Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <78104401AB7C4B22AF163FDB02062391@tedsdesk> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net> <78104401AB7C4B22AF163FDB02062391@tedsdesk> Message-ID: <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> Ted, You made some points in your reply that I think echo the intent of Michael's proposal. Aside from how it tries to get there, I am curious to hear from the community on its thoughts of the rationale. Who likes the idea of a policy to handle an IANA depleted situation, where the smaller organizations are less effected, in order to buy them time, while the larger organizations are forced towards IPv6. It is the largest IP consumers who will drive the vendors, and develop the market for IPv6 enabled equipment. It is the smallest organizations who need to remain on IPv4 until the shift has gained the necessary momentum. When the IANA pool is depleted, regardless of whether there is a black market, or a paid transfer policy, it is very difficult to see a sufficient supply of IPv4 resources, for the extra-large ISP. This means that these ISP will hit the wall first, and hit it the hardest. It is also this group who is more able to bear the burden of working with equipment vendors, and software developers, to push the necessary momentum towards IPv6. Would a policy proposal that supports this model be preferred by the community? Dan Alexander Comcast Cable ARIN AC -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Thursday, May 22, 2008 4:42 PM To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Thomas - > Mathbox > Sent: Thursday, May 22, 2008 12:22 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: > EquitableDistributionofIPv4Resources before IPv4 Run out > > > Ted, > > At the risk of receiving the wrath of the PPML Gods... > > > X-small: 61 cents/year > > X-Large fee is up to a /14. Anything over a /14 is no charge. > So, you cannot apply a single divisor that applies to all X-Large. The > /8 that they may also have is FREE. Most X-Large pay less than $.01 > per IP. > "...may also have is FREE..." is a reference to legacy allocations and I was not talking about that, those are a separate issue. As for the penny an IP address the X-large pays, sure on the surface that seems unfair. But, I will point out that precisely because they are X-large, and have so many IP's already, that in a time of IPv4 runout, they are going to be under intense pressure to both move to IPv6, and also to justify why they have so much IPv4 tied up. The small low-growth organizations who have maybe a /18 tied up, and who are experiencing maybe a 2% per year real growth in customer count, those folks aren't going to suffer in IPv4 runout time. They will be paying their bills, keeping people employed, keeping their customers happy, basically being good citizens. They will be able to sit back and weather the storm, and because they have so little IPv4 tied up as compared to the large holders, nobody is going to come banging on their door demanding they prove justification for their holdings, because even if what they have has a lot of unused numbers, the amount of unused numbering they have is so small it won't help any of the larger well-financed consumers of IP addressing for more than a few days of growth. The political and economic realities are that the X-larges are going to bear the brunt of the costs of switchover to IPv6 - and they will also suffer the largest customer losses, as they tell customers that they can't support IPv4, those customers who don't want to switch (think - all of them) will be going to the smaller providers. And when the large guys have ended up funding all the R&D for the production deployment of IPv6, by then the small guys will have a literal wealth of gear and deployment strategies to pick and choose from, as well as be able to know all the pitfalls, AND even better, since they really will be the last to covert over, their customers will not be able to carry out the threat of "quitting service and finding an ISP that will sell us IPv4" since there won't BE any ISP's left that will sell IPv4. > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number > > It is a two-way street... > > > of customers, so I am perfectly contented with the "smaller > allocation > > tax" of more cents per IP per year > > Exactly how much of that "tax-the-poor" does your company collect? > Other than providing a barrier to competition, how does it benefit > your company? > Naturally, our pricing has to be set according to what the other guy has his pricing set to - that's determined by competition. But, because we are smaller, we have much more flexibility in reducing our internal costs than the large guy does. So we pay more for numbering, but we can do things like using PC's running Quagga for BGP routers instead of Junipers, and the savings more than make up for the IP costs. (I'm not saying that we currently do this, but we have done so in the past - and the reliability is no worse than the commercial routers) It all has a way of working out in the end. Ted > Michael Thomas > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 2:32 PM > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > DistributionofIPv4Resources before IPv4 Run out > > > > > > Hey, whatever your smoking, I want some! > > > > ARIN -does- charge per IP address. I may have imbibed a number of > > hallucinogenic substances over the years but the bill we get from > > them every year is most definitely NOT a figment of my imagination! > > > > Or were you under the impression that ARIN was funded by > Tinker Bell > > and friends? > > > > In case you were, here is the ARIN fee schedule: > > > > http://www.arin.net/billing/fee_schedule.html > > > > Fees per IP address: > > > > X-small: 61 cents/year > > Small: 28 cents/year > > Medium: 6 cents/year > > Large: 3 cents/year > > > > and so forth. > > > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number of > > customers, so I am perfectly contented with the "smaller allocation > > tax" of more cents per IP per year > > > > If you go to Costco the giant bundle of toilet paper also > costs less > > per roll. That's just how things work in life. > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > Ted > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > Sent: Thursday, May 22, 2008 11:04 AM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > Ip do have value, as any business using the web to generate a > > > revenue stream can tell you. If Arin charged per ip, I doubt we > > > would be > > > running out of IP' addresses any time in the near future. > > You would > > > see a lot of IP addresses being returned that were not in use, at > > > the very least. > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > Thanks, > > > Charlie Sawyer > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 12:25 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > of IPv4Resources before IPv4 Run out > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > address distribution, which this proposal is trying to address. > > > > > > However, I think that while the moral is a Good Thing, > there is no > > > practical way to mandate it. > > > > > > If this proposal were to be supported I would ask that the author > > > modify it so that at the least, there would be an automatic > > > expiration to this. > > > > > > The cold hard fact of the matter is that ANY isp or other "small > > > or Very Small" organization that is NOT requesting IP addressing > > > at this time to meet their projected future needs, is likely to > > > get shafted when IPv4 runs out. > > > > > > On the day of IPv4 runout, if an ISP or organization does > not have a > > > supply of IPv4 to carry them forward for the immediate > future, due > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > Do we really want network administrators who aren't paying > > > attention to the gas guage to be driving the Internet into > > the future? > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > To: arin-ppml at arin.net > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution of > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > the ARIN Internet Resource Policy Evaluation Process, > the proposal > > > > is being posted to the ARIN Public Policy Mailing List > (PPML) and > > > > being placed on ARIN's website. > > > > > > > > The ARIN Advisory Council (AC) will review this > proposal at their > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > 2. Postpone their decision regarding the proposal > until the > > > > next regularly scheduled AC meeting in order to work with the > > > > author. The AC will work with the author to clarify, combine or > > > > divide the proposal. At their following meeting the AC > will accept > > > > or not accept the proposal. > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > proposal, the AC will explain their decision via the PPML. If a > > > > proposal is not accepted, then the author may elect to use the > > > > petition process to advance their proposal. If the > author elects > > > > not to petition or the petition fails, then the > proposal will be > > > > closed. > > > > > > > > The AC will assign shepherds in the near future. ARIN > will provide > > > > the names of the shepherds to the community via the PPML. > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > 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. > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > can be found > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > Mailing list subscription information can be found at: > > > > http://www.arin.net/mailing_lists/ > > > > > > > > Regards, > > > > > > > > Member Services > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > ## * ## > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > before IPv4 Run out > > > > > > > > Author: Michael K. Smith > > > > > > > > Proposal Version: 1 > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > Proposal type: new > > > > > > > > Policy term: permanent > > > > > > > > Policy statement: > > > > > > > > Upon receipt of the last allocation of IPv4 address > space to ARIN > > > > from IANA, ARIN will reserve address space within the allocated > > > > block for Organizations within the defined ARIN Organizational > > > > Size determinations (Extra Small, Small, Large, Extra > Large) based > > > > upon the utilization percentages for each group > gathered from the > > > > statistics of the last two IANA allocations to ARIN. > In order to > > > > make the allocation percentages mathematically feasible, the > > > > percentages will be rounded to the closest whole number and, > > > > subsequently, the the closest bit boundary for assignment the > > > > maximum allocation size for the Organization size as defined by > > > > ARIN. > > > > > > > > Once the final IANA allocation is received, ARIN will > publish the > > > > allocation percentages that will be used for the final > allocation > > > > to the PPML and ARIN website with the necessary documentation > > > > supporting the assignment of percentages. > > > > > > > > Rationale: > > > > > > > > Description: > > > > > > > > This policy is designed to allow Organizations of the various > > > > defined sizes to continue to receive address > allocations from the > > > > last available space and is slanted towards ensuring that > > > > organizations within the Large, Small and Extra Small > groups (and > > > > more specifically, the Small and Extra Small groups) > are able to > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > allocate such space. Given the statistics below, it is likely > > > > that Extra Large Organizations would get most or all of > the last > > > > remaining space because given the amount they have been > allocated > > > > to date. This policy would help ensure that other > Organizations > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > Example: > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > statistics are generated from IP allocations from 2006 > and 2007). > > > > This policy would require statistics to be limited to > the previous > > > > 2 IANA allocations to ARIN.) > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > Extra Large: 83.11% > > > > Large: 6.75% > > > > Small: 9.00% > > > > Extra Small: 1.14% > > > > > > > > With this example, ARIN would reserve address space in > the final > > > > IANA allocation according to those percentages, to the > extent that > > > > it is mathematically possible within the existing > range. In order > > > > to make the math work, rounding would give us: > > > > > > > > Extra Large: 83% > > > > Large: 7% > > > > Small: 9% > > > > Extra Small: 1% > > > > > > > > Who is affected: > > > > > > > > All ARIN Members will be affected by this policy. I > assume that > > > > smaller providers will benefit from having some space > available to > > > > them beyond where they would be with an organic > allocation model, > > > > and the Extra Large Organizations would experience some pain > > > > because, using the model above, they would be excluded > from being > > > > allocated 17% of the remaining space, even if they had > all of the > > > > necessary justifications for receiving allocations from within > > > > that space. > > > > > > > > Policy Enforcement: > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > allocations stay within the published percentages. > > > > > > > > Financial and Liability Implications: > > > > > > > > Financially, there may be additional resources required by ARIN > > > > Staff to allocate resources using this model. These resources > > > > might include application development, staff training > and tracking > > > > of allocations based upon the model. > > > > > > > > ARIN may have legal liability should Organizations that were > > > > denied space according to the model decide to contest > the legality > > > > of the policy in court. > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > allocation (roughly 2011). > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are > subscribed to the > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe > > > > or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From marla.azinger at frontiercorp.com Thu May 22 19:44:02 2008 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 22 May 2008 19:44:02 -0400 Subject: [arin-ppml] Policy Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net> <78104401AB7C4B22AF163FDB02062391@tedsdesk> <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1047C3C7EF4A@ROCH-EXCH1.corp.pvt> I would consider that type of proposal. Not sure if Im sold on it at this point but I think its worth looking at. Marla Frontier Communications -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Thursday, May 22, 2008 4:13 PM To: Ted Mittelstaedt; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out Ted, You made some points in your reply that I think echo the intent of Michael's proposal. Aside from how it tries to get there, I am curious to hear from the community on its thoughts of the rationale. Who likes the idea of a policy to handle an IANA depleted situation, where the smaller organizations are less effected, in order to buy them time, while the larger organizations are forced towards IPv6. It is the largest IP consumers who will drive the vendors, and develop the market for IPv6 enabled equipment. It is the smallest organizations who need to remain on IPv4 until the shift has gained the necessary momentum. When the IANA pool is depleted, regardless of whether there is a black market, or a paid transfer policy, it is very difficult to see a sufficient supply of IPv4 resources, for the extra-large ISP. This means that these ISP will hit the wall first, and hit it the hardest. It is also this group who is more able to bear the burden of working with equipment vendors, and software developers, to push the necessary momentum towards IPv6. Would a policy proposal that supports this model be preferred by the community? Dan Alexander Comcast Cable ARIN AC -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Thursday, May 22, 2008 4:42 PM To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Thomas - > Mathbox > Sent: Thursday, May 22, 2008 12:22 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: > EquitableDistributionofIPv4Resources before IPv4 Run out > > > Ted, > > At the risk of receiving the wrath of the PPML Gods... > > > X-small: 61 cents/year > > X-Large fee is up to a /14. Anything over a /14 is no charge. > So, you cannot apply a single divisor that applies to all X-Large. The > /8 that they may also have is FREE. Most X-Large pay less than $.01 > per IP. > "...may also have is FREE..." is a reference to legacy allocations and I was not talking about that, those are a separate issue. As for the penny an IP address the X-large pays, sure on the surface that seems unfair. But, I will point out that precisely because they are X-large, and have so many IP's already, that in a time of IPv4 runout, they are going to be under intense pressure to both move to IPv6, and also to justify why they have so much IPv4 tied up. The small low-growth organizations who have maybe a /18 tied up, and who are experiencing maybe a 2% per year real growth in customer count, those folks aren't going to suffer in IPv4 runout time. They will be paying their bills, keeping people employed, keeping their customers happy, basically being good citizens. They will be able to sit back and weather the storm, and because they have so little IPv4 tied up as compared to the large holders, nobody is going to come banging on their door demanding they prove justification for their holdings, because even if what they have has a lot of unused numbers, the amount of unused numbering they have is so small it won't help any of the larger well-financed consumers of IP addressing for more than a few days of growth. The political and economic realities are that the X-larges are going to bear the brunt of the costs of switchover to IPv6 - and they will also suffer the largest customer losses, as they tell customers that they can't support IPv4, those customers who don't want to switch (think - all of them) will be going to the smaller providers. And when the large guys have ended up funding all the R&D for the production deployment of IPv6, by then the small guys will have a literal wealth of gear and deployment strategies to pick and choose from, as well as be able to know all the pitfalls, AND even better, since they really will be the last to covert over, their customers will not be able to carry out the threat of "quitting service and finding an ISP that will sell us IPv4" since there won't BE any ISP's left that will sell IPv4. > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number > > It is a two-way street... > > > of customers, so I am perfectly contented with the "smaller > allocation > > tax" of more cents per IP per year > > Exactly how much of that "tax-the-poor" does your company collect? > Other than providing a barrier to competition, how does it benefit > your company? > Naturally, our pricing has to be set according to what the other guy has his pricing set to - that's determined by competition. But, because we are smaller, we have much more flexibility in reducing our internal costs than the large guy does. So we pay more for numbering, but we can do things like using PC's running Quagga for BGP routers instead of Junipers, and the savings more than make up for the IP costs. (I'm not saying that we currently do this, but we have done so in the past - and the reliability is no worse than the commercial routers) It all has a way of working out in the end. Ted > Michael Thomas > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 2:32 PM > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > DistributionofIPv4Resources before IPv4 Run out > > > > > > Hey, whatever your smoking, I want some! > > > > ARIN -does- charge per IP address. I may have imbibed a number of > > hallucinogenic substances over the years but the bill we get from > > them every year is most definitely NOT a figment of my imagination! > > > > Or were you under the impression that ARIN was funded by > Tinker Bell > > and friends? > > > > In case you were, here is the ARIN fee schedule: > > > > http://www.arin.net/billing/fee_schedule.html > > > > Fees per IP address: > > > > X-small: 61 cents/year > > Small: 28 cents/year > > Medium: 6 cents/year > > Large: 3 cents/year > > > > and so forth. > > > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number of > > customers, so I am perfectly contented with the "smaller allocation > > tax" of more cents per IP per year > > > > If you go to Costco the giant bundle of toilet paper also > costs less > > per roll. That's just how things work in life. > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > Ted > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > Sent: Thursday, May 22, 2008 11:04 AM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > Ip do have value, as any business using the web to generate a > > > revenue stream can tell you. If Arin charged per ip, I doubt we > > > would be running out of IP' addresses any time in the near future. > > You would > > > see a lot of IP addresses being returned that were not in use, at > > > the very least. > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > Thanks, > > > Charlie Sawyer > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 12:25 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > of IPv4Resources before IPv4 Run out > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > address distribution, which this proposal is trying to address. > > > > > > However, I think that while the moral is a Good Thing, > there is no > > > practical way to mandate it. > > > > > > If this proposal were to be supported I would ask that the author > > > modify it so that at the least, there would be an automatic > > > expiration to this. > > > > > > The cold hard fact of the matter is that ANY isp or other "small > > > or Very Small" organization that is NOT requesting IP addressing > > > at this time to meet their projected future needs, is likely to > > > get shafted when IPv4 runs out. > > > > > > On the day of IPv4 runout, if an ISP or organization does > not have a > > > supply of IPv4 to carry them forward for the immediate > future, due > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > Do we really want network administrators who aren't paying > > > attention to the gas guage to be driving the Internet into > > the future? > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > To: arin-ppml at arin.net > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution of > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > the ARIN Internet Resource Policy Evaluation Process, > the proposal > > > > is being posted to the ARIN Public Policy Mailing List > (PPML) and > > > > being placed on ARIN's website. > > > > > > > > The ARIN Advisory Council (AC) will review this > proposal at their > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > 2. Postpone their decision regarding the proposal > until the > > > > next regularly scheduled AC meeting in order to work with the > > > > author. The AC will work with the author to clarify, combine or > > > > divide the proposal. At their following meeting the AC > will accept > > > > or not accept the proposal. > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > proposal, the AC will explain their decision via the PPML. If a > > > > proposal is not accepted, then the author may elect to use the > > > > petition process to advance their proposal. If the > author elects > > > > not to petition or the petition fails, then the > proposal will be > > > > closed. > > > > > > > > The AC will assign shepherds in the near future. ARIN > will provide > > > > the names of the shepherds to the community via the PPML. > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > 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. > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > can be found > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > Mailing list subscription information can be found at: > > > > http://www.arin.net/mailing_lists/ > > > > > > > > Regards, > > > > > > > > Member Services > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > ## * ## > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > before IPv4 Run out > > > > > > > > Author: Michael K. Smith > > > > > > > > Proposal Version: 1 > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > Proposal type: new > > > > > > > > Policy term: permanent > > > > > > > > Policy statement: > > > > > > > > Upon receipt of the last allocation of IPv4 address > space to ARIN > > > > from IANA, ARIN will reserve address space within the allocated > > > > block for Organizations within the defined ARIN Organizational > > > > Size determinations (Extra Small, Small, Large, Extra > Large) based > > > > upon the utilization percentages for each group > gathered from the > > > > statistics of the last two IANA allocations to ARIN. > In order to > > > > make the allocation percentages mathematically feasible, the > > > > percentages will be rounded to the closest whole number and, > > > > subsequently, the the closest bit boundary for assignment the > > > > maximum allocation size for the Organization size as defined by > > > > ARIN. > > > > > > > > Once the final IANA allocation is received, ARIN will > publish the > > > > allocation percentages that will be used for the final > allocation > > > > to the PPML and ARIN website with the necessary documentation > > > > supporting the assignment of percentages. > > > > > > > > Rationale: > > > > > > > > Description: > > > > > > > > This policy is designed to allow Organizations of the various > > > > defined sizes to continue to receive address > allocations from the > > > > last available space and is slanted towards ensuring that > > > > organizations within the Large, Small and Extra Small > groups (and > > > > more specifically, the Small and Extra Small groups) > are able to > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > allocate such space. Given the statistics below, it is likely > > > > that Extra Large Organizations would get most or all of > the last > > > > remaining space because given the amount they have been > allocated > > > > to date. This policy would help ensure that other > Organizations > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > Example: > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > statistics are generated from IP allocations from 2006 > and 2007). > > > > This policy would require statistics to be limited to > the previous > > > > 2 IANA allocations to ARIN.) > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > Extra Large: 83.11% > > > > Large: 6.75% > > > > Small: 9.00% > > > > Extra Small: 1.14% > > > > > > > > With this example, ARIN would reserve address space in > the final > > > > IANA allocation according to those percentages, to the > extent that > > > > it is mathematically possible within the existing > range. In order > > > > to make the math work, rounding would give us: > > > > > > > > Extra Large: 83% > > > > Large: 7% > > > > Small: 9% > > > > Extra Small: 1% > > > > > > > > Who is affected: > > > > > > > > All ARIN Members will be affected by this policy. I > assume that > > > > smaller providers will benefit from having some space > available to > > > > them beyond where they would be with an organic > allocation model, > > > > and the Extra Large Organizations would experience some pain > > > > because, using the model above, they would be excluded > from being > > > > allocated 17% of the remaining space, even if they had > all of the > > > > necessary justifications for receiving allocations from within > > > > that space. > > > > > > > > Policy Enforcement: > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > allocations stay within the published percentages. > > > > > > > > Financial and Liability Implications: > > > > > > > > Financially, there may be additional resources required by ARIN > > > > Staff to allocate resources using this model. These resources > > > > might include application development, staff training > and tracking > > > > of allocations based upon the model. > > > > > > > > ARIN may have legal liability should Organizations that were > > > > denied space according to the model decide to contest > the legality > > > > of the policy in court. > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > allocation (roughly 2011). > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are > subscribed to the > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe > > > > or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From owen at delong.com Thu May 22 19:48:08 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 22 May 2008 16:48:08 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> References: <48343386.4060700@arin.net> <4834A80D.7050803@internap.com> <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> Message-ID: One problem with this theory is that end users don't fit into those categories and it's not clear if you reserve the space this way what happens to them. Would this simply terminate end-user assignments? Would they continue unmodified? What is the intent here? Owen On May 21, 2008, at 4:26 PM, Michael K. Smith - Adhost wrote: > Hello Scott: > > I'm working on a basis assumption that Extra Large organizations > request more addresses more frequently than any of the other > groups. So, if allocations proceed organically with the last IANA > allocation, there is a high likelihood that all of the last > allocation will go to the Extra Large organizations alone. So, in > an effort to help smaller providers "at the end" we should reserve > some space for them so that they can get space, even though they > request that space less frequently. > > If I understand the existing distribution methodology correctly, if > there were only a single /20 available at the end, an Extra Large > organization could still be allocated that space, even though they > had requested a /16. With my proposal, that last /20 would only be > available to either a Small or Extra Small Organization depending on > how much of the percentage for that group had been allocated already. > > I used the existing distribution because it seemed a defensible > position because it follows historical allocation patterns instead > of using some arbitrary assignment of percentages like 75% for Extra > Large, 10% for Large, etc. > > I hope that helps. Please feel free to ask for more clarification. > > Regards, > > Mike > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- >> bounces at arin.net] On Behalf >> Of Scott Leibrand >> Sent: Wednesday, May 21, 2008 3:54 PM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of >> IPv4 >> Resources before IPv4 Run out >> >> Michael, >> >> Can you help me understand the rationale for this proposal a bit >> better? >> >> As I understand it, this proposal would "lock in" the size-based >> distribution of addresses for the remaining ARIN free pool when the >> IANA >> free pool is exhausted. That's straightforward enough, but I'm a bit >> unclear as to the "why". How does locking in such ratios, and >> reserving >> space for each group, help ensure a more equitable distribution? >> >> Thanks, >> Scott >> >> Member Services wrote: >>> ARIN received the following policy proposal. In accordance with >>> the ARIN >>> Internet Resource Policy Evaluation Process, the proposal is being >>> posted to the ARIN Public Policy Mailing List (PPML) and being >>> placed on >>> ARIN's website. >>> >>> The ARIN Advisory Council (AC) will review this proposal at their >>> next >>> regularly scheduled meeting. The AC may decide to: >>> >>> 1. Accept the proposal as written. If the AC accepts the >>> proposal, >>> it will be posted as a formal policy proposal to PPML and it will be >>> presented at a Public Policy Meeting. >>> >>> 2. Postpone their decision regarding the proposal until the >>> next >>> regularly scheduled AC meeting in order to work with the author. >>> The AC >>> will work with the author to clarify, combine or divide the >>> proposal. At >>> their following meeting the AC will accept or not accept the >>> proposal. >>> >>> 3. Not accept the proposal. If the AC does not accept the >>> proposal, >>> the AC will explain their decision via the PPML. If a proposal is >>> not >>> accepted, then the author may elect to use the petition process to >>> advance their proposal. If the author elects not to petition or the >>> petition fails, then the proposal will be closed. >>> >>> The AC will assign shepherds in the near future. ARIN will provide >>> the >>> names of the shepherds to the community via the PPML. >>> >>> In the meantime, the AC invites everyone to comment on this >>> 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. >>> >>> The ARIN Internet Resource Policy Evaluation Process can be found >>> at: >>> http://www.arin.net/policy/irpep.html >>> >>> Mailing list subscription information can be found at: >>> http://www.arin.net/mailing_lists/ >>> >>> Regards, >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> Policy Proposal Name: Equitable Distribution of IPv4 Resources >>> before >>> IPv4 Run out >>> >>> Author: Michael K. Smith >>> >>> Proposal Version: 1 >>> >>> Submission Date: 05/20/2008 >>> >>> Proposal type: new >>> >>> Policy term: permanent >>> >>> Policy statement: >>> >>> Upon receipt of the last allocation of IPv4 address space to ARIN >>> from >>> IANA, ARIN will reserve address space within the allocated block for >>> Organizations within the defined ARIN Organizational Size >>> determinations >>> (Extra Small, Small, Large, Extra Large) based upon the utilization >>> percentages for each group gathered from the statistics of the >>> last two >>> IANA allocations to ARIN. In order to make the allocation >>> percentages >>> mathematically feasible, the percentages will be rounded to the >>> closest >>> whole number and, subsequently, the the closest bit boundary for >>> assignment the maximum allocation size for the Organization size as >>> defined by ARIN. >>> >>> Once the final IANA allocation is received, ARIN will publish the >>> allocation percentages that will be used for the final allocation >>> to the >>> PPML and ARIN website with the necessary documentation supporting >>> the >>> assignment of percentages. >>> >>> Rationale: >>> >>> Description: >>> >>> This policy is designed to allow Organizations of the various >>> defined >>> sizes to continue to receive address allocations from the last >>> available >>> space and is slanted towards ensuring that organizations within the >>> Large, Small and Extra Small groups (and more specifically, the >>> Small >>> and Extra Small groups) are able to get additional IPv4 space at >>> the end >>> of the ARIN's ability to allocate such space. Given the statistics >>> below, it is likely that Extra Large Organizations would get most >>> or all >>> of the last remaining space because given the amount they have been >>> allocated to date. This policy would help ensure that other >>> Organizations had a statistically equal opportunity to receive >>> space as >>> well. >>> >>> >>> Example: >>> >>> Please see http://www.arin.net/statistics/index.html (Note: the >>> statistics are generated from IP allocations from 2006 and 2007). >>> This >>> policy would require statistics to be limited to the previous 2 IANA >>> allocations to ARIN.) >>> >>> The present distribution as of May 20th 2008 is: >>> >>> Extra Large: 83.11% >>> Large: 6.75% >>> Small: 9.00% >>> Extra Small: 1.14% >>> >>> With this example, ARIN would reserve address space in the final >>> IANA >>> allocation according to those percentages, to the extent that it is >>> mathematically possible within the existing range. In order to >>> make the >>> math work, rounding would give us: >>> >>> Extra Large: 83% >>> Large: 7% >>> Small: 9% >>> Extra Small: 1% >>> >>> Who is affected: >>> >>> All ARIN Members will be affected by this policy. I assume that >>> smaller >>> providers will benefit from having some space available to them >>> beyond >>> where they would be with an organic allocation model, and the Extra >>> Large Organizations would experience some pain because, using the >>> model >>> above, they would be excluded from being allocated 17% of the >>> remaining >>> space, even if they had all of the necessary justifications for >>> receiving allocations from within that space. >>> >>> Policy Enforcement: >>> >>> ARIN staff will have to enforce this policy and ensure that >>> allocations >>> stay within the published percentages. >>> >>> Financial and Liability Implications: >>> >>> Financially, there may be additional resources required by ARIN >>> Staff to >>> allocate resources using this model. These resources might include >>> application development, staff training and tracking of allocations >>> based upon the model. >>> >>> ARIN may have legal liability should Organizations that were denied >>> space according to the model decide to contest the legality of the >>> policy in court. >>> >>> Timetable for implementation: Upon receipt of finall IANA >>> allocation >>> (roughly 2011). >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the >>> ARIN Public >> Policy >>> Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From mksmith at adhost.com Thu May 22 20:00:49 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 22 May 2008 17:00:49 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: References: <48343386.4060700@arin.net> <4834A80D.7050803@internap.com> <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> Message-ID: <17838240D9A5544AAA5FF95F8D520316040989A0@ad-exh01.adhost.lan> Hello Owen: The intent was certainly not to exclude end users. Data concerning allocations to end users shows only the number of processed requests and doesn't break out the actual allocation sizes. I assume that the data necessary to include the end users is available and can be incorporated into the distribution model. Regards, Mike > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, May 22, 2008 4:48 PM > To: Michael K. Smith - Adhost > Cc: Scott Leibrand; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 > Resources before IPv4 Run out > > One problem with this theory is that end users don't fit into those > categories > and it's not clear if you reserve the space this way what happens to > them. > Would this simply terminate end-user assignments? Would they continue > unmodified? > > What is the intent here? > > Owen > > On May 21, 2008, at 4:26 PM, Michael K. Smith - Adhost wrote: > > > Hello Scott: > > > > I'm working on a basis assumption that Extra Large organizations > > request more addresses more frequently than any of the other > > groups. So, if allocations proceed organically with the last IANA > > allocation, there is a high likelihood that all of the last > > allocation will go to the Extra Large organizations alone. So, in > > an effort to help smaller providers "at the end" we should reserve > > some space for them so that they can get space, even though they > > request that space less frequently. > > > > If I understand the existing distribution methodology correctly, if > > there were only a single /20 available at the end, an Extra Large > > organization could still be allocated that space, even though they > > had requested a /16. With my proposal, that last /20 would only be > > available to either a Small or Extra Small Organization depending on > > how much of the percentage for that group had been allocated already. > > > > I used the existing distribution because it seemed a defensible > > position because it follows historical allocation patterns instead > > of using some arbitrary assignment of percentages like 75% for Extra > > Large, 10% for Large, etc. > > > > I hope that helps. Please feel free to ask for more clarification. > > > > Regards, > > > > Mike > > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- > >> bounces at arin.net] On Behalf > >> Of Scott Leibrand > >> Sent: Wednesday, May 21, 2008 3:54 PM > >> To: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of > >> IPv4 > >> Resources before IPv4 Run out > >> > >> Michael, > >> > >> Can you help me understand the rationale for this proposal a bit > >> better? > >> > >> As I understand it, this proposal would "lock in" the size-based > >> distribution of addresses for the remaining ARIN free pool when the > >> IANA > >> free pool is exhausted. That's straightforward enough, but I'm a bit > >> unclear as to the "why". How does locking in such ratios, and > >> reserving > >> space for each group, help ensure a more equitable distribution? > >> > >> Thanks, > >> Scott > >> > >> Member Services wrote: > >>> ARIN received the following policy proposal. In accordance with > >>> the ARIN > >>> Internet Resource Policy Evaluation Process, the proposal is being > >>> posted to the ARIN Public Policy Mailing List (PPML) and being > >>> placed on > >>> ARIN's website. > >>> > >>> The ARIN Advisory Council (AC) will review this proposal at their > >>> next > >>> regularly scheduled meeting. The AC may decide to: > >>> > >>> 1. Accept the proposal as written. If the AC accepts the > >>> proposal, > >>> it will be posted as a formal policy proposal to PPML and it will be > >>> presented at a Public Policy Meeting. > >>> > >>> 2. Postpone their decision regarding the proposal until the > >>> next > >>> regularly scheduled AC meeting in order to work with the author. > >>> The AC > >>> will work with the author to clarify, combine or divide the > >>> proposal. At > >>> their following meeting the AC will accept or not accept the > >>> proposal. > >>> > >>> 3. Not accept the proposal. If the AC does not accept the > >>> proposal, > >>> the AC will explain their decision via the PPML. If a proposal is > >>> not > >>> accepted, then the author may elect to use the petition process to > >>> advance their proposal. If the author elects not to petition or the > >>> petition fails, then the proposal will be closed. > >>> > >>> The AC will assign shepherds in the near future. ARIN will provide > >>> the > >>> names of the shepherds to the community via the PPML. > >>> > >>> In the meantime, the AC invites everyone to comment on this > >>> 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. > >>> > >>> The ARIN Internet Resource Policy Evaluation Process can be found > >>> at: > >>> http://www.arin.net/policy/irpep.html > >>> > >>> Mailing list subscription information can be found at: > >>> http://www.arin.net/mailing_lists/ > >>> > >>> Regards, > >>> > >>> Member Services > >>> American Registry for Internet Numbers (ARIN) > >>> > >>> > >>> ## * ## > >>> > >>> > >>> Policy Proposal Name: Equitable Distribution of IPv4 Resources > >>> before > >>> IPv4 Run out > >>> > >>> Author: Michael K. Smith > >>> > >>> Proposal Version: 1 > >>> > >>> Submission Date: 05/20/2008 > >>> > >>> Proposal type: new > >>> > >>> Policy term: permanent > >>> > >>> Policy statement: > >>> > >>> Upon receipt of the last allocation of IPv4 address space to ARIN > >>> from > >>> IANA, ARIN will reserve address space within the allocated block for > >>> Organizations within the defined ARIN Organizational Size > >>> determinations > >>> (Extra Small, Small, Large, Extra Large) based upon the utilization > >>> percentages for each group gathered from the statistics of the > >>> last two > >>> IANA allocations to ARIN. In order to make the allocation > >>> percentages > >>> mathematically feasible, the percentages will be rounded to the > >>> closest > >>> whole number and, subsequently, the the closest bit boundary for > >>> assignment the maximum allocation size for the Organization size as > >>> defined by ARIN. > >>> > >>> Once the final IANA allocation is received, ARIN will publish the > >>> allocation percentages that will be used for the final allocation > >>> to the > >>> PPML and ARIN website with the necessary documentation supporting > >>> the > >>> assignment of percentages. > >>> > >>> Rationale: > >>> > >>> Description: > >>> > >>> This policy is designed to allow Organizations of the various > >>> defined > >>> sizes to continue to receive address allocations from the last > >>> available > >>> space and is slanted towards ensuring that organizations within the > >>> Large, Small and Extra Small groups (and more specifically, the > >>> Small > >>> and Extra Small groups) are able to get additional IPv4 space at > >>> the end > >>> of the ARIN's ability to allocate such space. Given the statistics > >>> below, it is likely that Extra Large Organizations would get most > >>> or all > >>> of the last remaining space because given the amount they have been > >>> allocated to date. This policy would help ensure that other > >>> Organizations had a statistically equal opportunity to receive > >>> space as > >>> well. > >>> > >>> > >>> Example: > >>> > >>> Please see http://www.arin.net/statistics/index.html (Note: the > >>> statistics are generated from IP allocations from 2006 and 2007). > >>> This > >>> policy would require statistics to be limited to the previous 2 IANA > >>> allocations to ARIN.) > >>> > >>> The present distribution as of May 20th 2008 is: > >>> > >>> Extra Large: 83.11% > >>> Large: 6.75% > >>> Small: 9.00% > >>> Extra Small: 1.14% > >>> > >>> With this example, ARIN would reserve address space in the final > >>> IANA > >>> allocation according to those percentages, to the extent that it is > >>> mathematically possible within the existing range. In order to > >>> make the > >>> math work, rounding would give us: > >>> > >>> Extra Large: 83% > >>> Large: 7% > >>> Small: 9% > >>> Extra Small: 1% > >>> > >>> Who is affected: > >>> > >>> All ARIN Members will be affected by this policy. I assume that > >>> smaller > >>> providers will benefit from having some space available to them > >>> beyond > >>> where they would be with an organic allocation model, and the Extra > >>> Large Organizations would experience some pain because, using the > >>> model > >>> above, they would be excluded from being allocated 17% of the > >>> remaining > >>> space, even if they had all of the necessary justifications for > >>> receiving allocations from within that space. > >>> > >>> Policy Enforcement: > >>> > >>> ARIN staff will have to enforce this policy and ensure that > >>> allocations > >>> stay within the published percentages. > >>> > >>> Financial and Liability Implications: > >>> > >>> Financially, there may be additional resources required by ARIN > >>> Staff to > >>> allocate resources using this model. These resources might include > >>> application development, staff training and tracking of allocations > >>> based upon the model. > >>> > >>> ARIN may have legal liability should Organizations that were denied > >>> space according to the model decide to contest the legality of the > >>> policy in court. > >>> > >>> Timetable for implementation: Upon receipt of finall IANA > >>> allocation > >>> (roughly 2011). > >>> > >>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to the > >>> ARIN Public > >> Policy > >>> Mailing List (ARIN-PPML at arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > > if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From mksmith at adhost.com Thu May 22 20:21:43 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 22 May 2008 17:21:43 -0700 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk> <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316040989A3@ad-exh01.adhost.lan> Hello Daniel: I'm sure you can guess my position, but the idea that smaller organizations would be more adversely affected at the point of depletion was part of my rationale behind submitting a policy that was tilted at benefitting those organizations. I had thought through several different models for distribution, including flat percentages based upon org size, a model based upon only allocating in halves the last IANA allocation (if a /14 is left, you can't allocate the /14 to one org, only half of it, then half the remaining, etc. But, that got ugly fast), and reserving space based upon the allocation size for the groups (x number of /20's, x number of /22's, etc.). Using the percentages from previous allocations seemed the most equitable and, thus, the most likely to be palatable to orgs of every size, provided the bigger concept of helping the smaller orgs was accepted by the community. If anyone has a better model I am all ears. Regards, Mike > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Alexander, Daniel > Sent: Thursday, May 22, 2008 4:13 PM > To: Ted Mittelstaedt; arin-ppml at arin.net > Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources > before IPv4 Run out > > Ted, > > You made some points in your reply that I think echo the intent of > Michael's proposal. Aside from how it tries to get there, I am curious > to hear from the community on its thoughts of the rationale. > > Who likes the idea of a policy to handle an IANA depleted situation, > where the smaller organizations are less effected, in order to buy them > time, while the larger organizations are forced towards IPv6. It is the > largest IP consumers who will drive the vendors, and develop the market > for IPv6 enabled equipment. It is the smallest organizations who need to > remain on IPv4 until the shift has gained the necessary momentum. > > When the IANA pool is depleted, regardless of whether there is a black > market, or a paid transfer policy, it is very difficult to see a > sufficient supply of IPv4 resources, for the extra-large ISP. This means > that these ISP will hit the wall first, and hit it the hardest. It is > also this group who is more able to bear the burden of working with > equipment vendors, and software developers, to push the necessary > momentum towards IPv6. Would a policy proposal that supports this model > be preferred by the community? > > Dan Alexander > Comcast Cable > ARIN AC > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Thursday, May 22, 2008 4:42 PM > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Thomas - > > Mathbox > > Sent: Thursday, May 22, 2008 12:22 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: > > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > Ted, > > > > At the risk of receiving the wrath of the PPML Gods... > > > > > X-small: 61 cents/year > > > > X-Large fee is up to a /14. Anything over a /14 is no charge. > > So, you cannot apply a single divisor that applies to all X-Large. The > > > /8 that they may also have is FREE. Most X-Large pay less than $.01 > > per IP. > > > > "...may also have is FREE..." is a reference to legacy allocations and > I was not talking about that, those are a separate issue. > > As for the penny an IP address the X-large pays, sure on the surface > that seems unfair. But, I will point out that precisely because they > are X-large, and have so many IP's already, that in a time of IPv4 > runout, they are going to be under intense pressure to both move to > IPv6, and also to justify why they have so much IPv4 tied up. > > The small low-growth organizations who have maybe a /18 tied up, and who > are experiencing maybe a 2% per year real growth in customer count, > those folks aren't going to suffer in IPv4 runout time. They will be > paying their bills, keeping people employed, keeping their customers > happy, basically being good citizens. > They will be able to sit back and weather the storm, and because they > have so little IPv4 tied up as compared to the large holders, nobody is > going to come banging on their door demanding they prove justification > for their holdings, because even if what they have has a lot of unused > numbers, the amount of unused numbering they have is so small it won't > help any of the larger well-financed consumers of IP addressing for more > than a few days of growth. > > The political and economic realities are that the X-larges are going to > bear the brunt of the costs of switchover to IPv6 - and they will also > suffer the largest customer losses, as they tell customers that they > can't support IPv4, those customers who don't want to switch (think - > all of them) will be going to the smaller providers. > > And when the large guys have ended up funding all the R&D for the > production deployment of IPv6, by then the small guys will have a > literal wealth of gear and deployment strategies to pick and choose > from, as well as be able to know all the pitfalls, AND even better, > since they really will be the last to covert over, their customers will > not be able to carry out the threat of "quitting service and finding an > ISP that will sell us IPv4" > since there won't BE any ISP's left that will sell IPv4. > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per customer, > > > because we have to carry more route entries for the same number > > > > It is a two-way street... > > > > > of customers, so I am perfectly contented with the "smaller > > allocation > > > tax" of more cents per IP per year > > > > Exactly how much of that "tax-the-poor" does your company collect? > > Other than providing a barrier to competition, how does it benefit > > your company? > > > > Naturally, our pricing has to be set according to what the other guy has > his pricing set to - that's determined by competition. > But, because we are smaller, we have much more flexibility in reducing > our internal costs than the large guy does. So we pay more for > numbering, but we can do things like using PC's running Quagga for BGP > routers instead of Junipers, and the savings more than make up for the > IP costs. (I'm not saying that we currently do this, but we have done > so in the past - and the reliability is no worse than the commercial > routers) It all has a way of working out in the end. > > Ted > > > Michael Thomas > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 2:32 PM > > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > DistributionofIPv4Resources before IPv4 Run out > > > > > > > > > Hey, whatever your smoking, I want some! > > > > > > ARIN -does- charge per IP address. I may have imbibed a number of > > > hallucinogenic substances over the years but the bill we get from > > > them every year is most definitely NOT a figment of my imagination! > > > > > > Or were you under the impression that ARIN was funded by > > Tinker Bell > > > and friends? > > > > > > In case you were, here is the ARIN fee schedule: > > > > > > http://www.arin.net/billing/fee_schedule.html > > > > > > Fees per IP address: > > > > > > X-small: 61 cents/year > > > Small: 28 cents/year > > > Medium: 6 cents/year > > > Large: 3 cents/year > > > > > > and so forth. > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per customer, > > > because we have to carry more route entries for the same number of > > > customers, so I am perfectly contented with the "smaller allocation > > > tax" of more cents per IP per year > > > > > > If you go to Costco the giant bundle of toilet paper also > > costs less > > > per roll. That's just how things work in life. > > > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > > Sent: Thursday, May 22, 2008 11:04 AM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > > > > Ip do have value, as any business using the web to generate a > > > > revenue stream can tell you. If Arin charged per ip, I doubt we > > > > would be > > > > running out of IP' addresses any time in the near future. > > > You would > > > > see a lot of IP addresses being returned that were not in use, at > > > > the very least. > > > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > > > > Thanks, > > > > Charlie Sawyer > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > > Sent: Thursday, May 22, 2008 12:25 PM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > of IPv4Resources before IPv4 Run out > > > > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > > address distribution, which this proposal is trying to address. > > > > > > > > However, I think that while the moral is a Good Thing, > > there is no > > > > practical way to mandate it. > > > > > > > > If this proposal were to be supported I would ask that the author > > > > modify it so that at the least, there would be an automatic > > > > expiration to this. > > > > > > > > The cold hard fact of the matter is that ANY isp or other "small > > > > or Very Small" organization that is NOT requesting IP addressing > > > > at this time to meet their projected future needs, is likely to > > > > get shafted when IPv4 runs out. > > > > > > > > On the day of IPv4 runout, if an ISP or organization does > > not have a > > > > supply of IPv4 to carry them forward for the immediate > > future, due > > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > > > Do we really want network administrators who aren't paying > > > > attention to the gas guage to be driving the Internet into > > > the future? > > > > > > > > Ted > > > > > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > > To: arin-ppml at arin.net > > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution of > > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > > the ARIN Internet Resource Policy Evaluation Process, > > the proposal > > > > > is being posted to the ARIN Public Policy Mailing List > > (PPML) and > > > > > being placed on ARIN's website. > > > > > > > > > > The ARIN Advisory Council (AC) will review this > > proposal at their > > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > > > 2. Postpone their decision regarding the proposal > > until the > > > > > next regularly scheduled AC meeting in order to work with the > > > > > author. The AC will work with the author to clarify, combine or > > > > > divide the proposal. At their following meeting the AC > > will accept > > > > > or not accept the proposal. > > > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > > proposal, the AC will explain their decision via the PPML. If a > > > > > proposal is not accepted, then the author may elect to use the > > > > > petition process to advance their proposal. If the > > author elects > > > > > not to petition or the petition fails, then the > > proposal will be > > > > > closed. > > > > > > > > > > The AC will assign shepherds in the near future. ARIN > > will provide > > > > > the names of the shepherds to the community via the PPML. > > > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > > 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. > > > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > > can be found > > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > > > Mailing list subscription information can be found at: > > > > > http://www.arin.net/mailing_lists/ > > > > > > > > > > Regards, > > > > > > > > > > Member Services > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > ## * ## > > > > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > > before IPv4 Run out > > > > > > > > > > Author: Michael K. Smith > > > > > > > > > > Proposal Version: 1 > > > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > > > Proposal type: new > > > > > > > > > > Policy term: permanent > > > > > > > > > > Policy statement: > > > > > > > > > > Upon receipt of the last allocation of IPv4 address > > space to ARIN > > > > > from IANA, ARIN will reserve address space within the allocated > > > > > block for Organizations within the defined ARIN Organizational > > > > > Size determinations (Extra Small, Small, Large, Extra > > Large) based > > > > > upon the utilization percentages for each group > > gathered from the > > > > > statistics of the last two IANA allocations to ARIN. > > In order to > > > > > make the allocation percentages mathematically feasible, the > > > > > percentages will be rounded to the closest whole number and, > > > > > subsequently, the the closest bit boundary for assignment the > > > > > maximum allocation size for the Organization size as defined by > > > > > ARIN. > > > > > > > > > > Once the final IANA allocation is received, ARIN will > > publish the > > > > > allocation percentages that will be used for the final > > allocation > > > > > to the PPML and ARIN website with the necessary documentation > > > > > supporting the assignment of percentages. > > > > > > > > > > Rationale: > > > > > > > > > > Description: > > > > > > > > > > This policy is designed to allow Organizations of the various > > > > > defined sizes to continue to receive address > > allocations from the > > > > > last available space and is slanted towards ensuring that > > > > > organizations within the Large, Small and Extra Small > > groups (and > > > > > more specifically, the Small and Extra Small groups) > > are able to > > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > > allocate such space. Given the statistics below, it is likely > > > > > that Extra Large Organizations would get most or all of > > the last > > > > > remaining space because given the amount they have been > > allocated > > > > > to date. This policy would help ensure that other > > Organizations > > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > > > > Example: > > > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > > statistics are generated from IP allocations from 2006 > > and 2007). > > > > > This policy would require statistics to be limited to > > the previous > > > > > 2 IANA allocations to ARIN.) > > > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > > > Extra Large: 83.11% > > > > > Large: 6.75% > > > > > Small: 9.00% > > > > > Extra Small: 1.14% > > > > > > > > > > With this example, ARIN would reserve address space in > > the final > > > > > IANA allocation according to those percentages, to the > > extent that > > > > > it is mathematically possible within the existing > > range. In order > > > > > to make the math work, rounding would give us: > > > > > > > > > > Extra Large: 83% > > > > > Large: 7% > > > > > Small: 9% > > > > > Extra Small: 1% > > > > > > > > > > Who is affected: > > > > > > > > > > All ARIN Members will be affected by this policy. I > > assume that > > > > > smaller providers will benefit from having some space > > available to > > > > > them beyond where they would be with an organic > > allocation model, > > > > > and the Extra Large Organizations would experience some pain > > > > > because, using the model above, they would be excluded > > from being > > > > > allocated 17% of the remaining space, even if they had > > all of the > > > > > necessary justifications for receiving allocations from within > > > > > that space. > > > > > > > > > > Policy Enforcement: > > > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > > allocations stay within the published percentages. > > > > > > > > > > Financial and Liability Implications: > > > > > > > > > > Financially, there may be additional resources required by ARIN > > > > > Staff to allocate resources using this model. These resources > > > > > might include application development, staff training > > and tracking > > > > > of allocations based upon the model. > > > > > > > > > > ARIN may have legal liability should Organizations that were > > > > > denied space according to the model decide to contest > > the legality > > > > > of the policy in court. > > > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > > allocation (roughly 2011). > > > > > > > > > > _______________________________________________ > > > > > PPML > > > > > You are receiving this message because you are > > subscribed to the > > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe > > > > > or manage your mailing list subscription at: > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > Please contact the ARIN Member Services Help Desk at > > > > > 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From stephen at sprunk.org Thu May 22 20:37:22 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 22 May 2008 19:37:22 -0500 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk> <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> Message-ID: <25B2B51C5F5B4411A9E47D60958DDE90@atlanta.polycom.com> Thus spake "Alexander, Daniel" > Who likes the idea of a policy to handle an IANA depleted situation, > where the smaller organizations are less effected, in order to buy them > time, while the larger organizations are forced towards IPv6. It is the > largest IP consumers who will drive the vendors, and develop the market > for IPv6 enabled equipment. It is the smallest organizations who need to > remain on IPv4 until the shift has gained the necessary momentum. > > When the IANA pool is depleted, regardless of whether there is a black > market, or a paid transfer policy, it is very difficult to see a > sufficient supply of IPv4 resources, for the extra-large ISP. This means > that these ISP will hit the wall first, and hit it the hardest. It is > also this group who is more able to bear the burden of working with > equipment vendors, and software developers, to push the necessary > momentum towards IPv6. Would a policy proposal that supports this model > be preferred by the community? While I agree with what you're saying, I think that's also what will happen _without_ any policy to cause it. Large operators know their burn rate and how many customers they can add before we all hit the wall, and they know they have to be planning for it (and pressuring their vendors) now. The rest of us don't really have the power to do anything until a certain half-dozen ISPs that serve most of the eyeballs in North America roll out v6, after which the equipment and software will be available for everyone else to follow them. 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 From Daniel_Alexander at Cable.Comcast.com Thu May 22 21:00:28 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 22 May 2008 21:00:28 -0400 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk> <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> <25B2B51C5F5B4411A9E47D60958DDE90@atlanta.polycom.com> Message-ID: <997BC128AE961E4A8B880CD7442D9480D78A51@NJCHLEXCMB01.cable.comcast.com> You are right. The largest ISP will reach the same end state regardless. I think the intent of the proposal, however was to prevent the larger ISP from consuming every available remaining IP, leaving nothing for the smaller orgs during the transition. The question is how to buy some time for the smaller orgs while the largest orgs work through the transition. ________________________________ From: Stephen Sprunk [mailto:stephen at sprunk.org] Sent: Thu 5/22/2008 8:37 PM To: Alexander, Daniel; Ted Mittelstaedt Cc: ARIN PPML Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out Thus spake "Alexander, Daniel" > Who likes the idea of a policy to handle an IANA depleted situation, > where the smaller organizations are less effected, in order to buy them > time, while the larger organizations are forced towards IPv6. It is the > largest IP consumers who will drive the vendors, and develop the market > for IPv6 enabled equipment. It is the smallest organizations who need to > remain on IPv4 until the shift has gained the necessary momentum. > > When the IANA pool is depleted, regardless of whether there is a black > market, or a paid transfer policy, it is very difficult to see a > sufficient supply of IPv4 resources, for the extra-large ISP. This means > that these ISP will hit the wall first, and hit it the hardest. It is > also this group who is more able to bear the burden of working with > equipment vendors, and software developers, to push the necessary > momentum towards IPv6. Would a policy proposal that supports this model > be preferred by the community? While I agree with what you're saying, I think that's also what will happen _without_ any policy to cause it. Large operators know their burn rate and how many customers they can add before we all hit the wall, and they know they have to be planning for it (and pressuring their vendors) now. The rest of us don't really have the power to do anything until a certain half-dozen ISPs that serve most of the eyeballs in North America roll out v6, after which the equipment and software will be available for everyone else to follow them. 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 From bicknell at ufp.org Thu May 22 21:04:48 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 22 May 2008 21:04:48 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> References: <48343386.4060700@arin.net> <4834A80D.7050803@internap.com> <17838240D9A5544AAA5FF95F8D52031604098826@ad-exh01.adhost.lan> Message-ID: <20080523010448.GB36810@ussenterprise.ufp.org> In a message written on Wed, May 21, 2008 at 04:26:19PM -0700, Michael K. Smith - Adhost wrote: > I'm working on a basis assumption that Extra Large organizations > request more addresses more frequently than any of the other groups. > So, if allocations proceed organically with the last IANA allocation, > there is a high likelihood that all of the last allocation will go > to the Extra Large organizations alone. So, in an effort to help > smaller providers "at the end" we should reserve some space for > them so that they can get space, even though they request that space > less frequently. I believe this assumption is false. Section 4.2.4 of the NRPM covers ISP's returning for additional space, which I believe is the most relevant section here. Note that end users and an ISP's very first request to ARIN have different criteria. http://www.arin.net/policy/nrpm.html#four24 4.2.4.4. Twelve months After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses. Also note this was just changed to 12 months by proposal 2007-22 (http://www.arin.net/policy/proposals/2007_22.html). Anyway, if ARIN is allocating the correct size blocks all ISP's have been returning to ARIN approximately once every six months, and will now be returning to ARIN approximately once every twelve months. The size of the allocation should have no real bearing on this situation. -- 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: 187 bytes Desc: not available URL: From Daniel_Alexander at Cable.Comcast.com Thu May 22 21:40:03 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 22 May 2008 21:40:03 -0400 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out References: <17838240D9A5544AAA5FF95F8D520316040989A3@ad-exh01.adhost.lan> Message-ID: <997BC128AE961E4A8B880CD7442D9480D78A52@NJCHLEXCMB01.cable.comcast.com> Michael, One thought with the proposal, is that you end up with a similar situation as with the depleting IANA pool. There are discussions currently under way to distribute the last /8s to the RIR to provide each Registry with a known end allocation. This way an RIR wouldn't receive what would become it's last allocation, without it knowing it, because the other RIR deplete the pool shortly after. This proposal does a similar thing in that it tries to protect the smaller organizations from unexpectedly losing out because of the higher consumption of the larger orgs. One consideration is where do we draw the line. Do we then try and protect the organizations within each size category from being blind-sided from other orgs of a similar size? In the end, I can see three high level models that the community has been considering. One is to allow paid transfers and open things up to market forces. Another, like the one you propose, is to attempt a fair, final distribution of whats left. A third would be to restrict demand or ration what's left. All have their pros and cons, and it would be great to have more options discussed on this list. I'll throw a thought I have had into this mix, which is similar to what you proposed. Wait until the IANA pool has been depleted and ARINs remaining reserve is equivelant to a /8. Then implement a window where an org cannot receive an allocation more than once every six months. In addition to this, enact a maximum allocation size of, say a /18 or /17. This in effect, shuts out the largest ISP, while still affording them allocations during transition. In the mean time, the needs of the smaller orgs continue to be met by the Registry. In the end, I think your proposal can initiate some productive debate, and should continue to be discussed. Thank you for putting forth the effort. Dan ________________________________ From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] Sent: Thu 5/22/2008 8:21 PM To: Alexander, Daniel; arin-ppml at arin.net Subject: RE: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out Hello Daniel: I'm sure you can guess my position, but the idea that smaller organizations would be more adversely affected at the point of depletion was part of my rationale behind submitting a policy that was tilted at benefitting those organizations. I had thought through several different models for distribution, including flat percentages based upon org size, a model based upon only allocating in halves the last IANA allocation (if a /14 is left, you can't allocate the /14 to one org, only half of it, then half the remaining, etc. But, that got ugly fast), and reserving space based upon the allocation size for the groups (x number of /20's, x number of /22's, etc.). Using the percentages from previous allocations seemed the most equitable and, thus, the most likely to be palatable to orgs of every size, provided the bigger concept of helping the smaller orgs was accepted by the community. If anyone has a better model I am all ears. Regards, Mike > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Alexander, Daniel > Sent: Thursday, May 22, 2008 4:13 PM > To: Ted Mittelstaedt; arin-ppml at arin.net > Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources > before IPv4 Run out > > Ted, > > You made some points in your reply that I think echo the intent of > Michael's proposal. Aside from how it tries to get there, I am curious > to hear from the community on its thoughts of the rationale. > > Who likes the idea of a policy to handle an IANA depleted situation, > where the smaller organizations are less effected, in order to buy them > time, while the larger organizations are forced towards IPv6. It is the > largest IP consumers who will drive the vendors, and develop the market > for IPv6 enabled equipment. It is the smallest organizations who need to > remain on IPv4 until the shift has gained the necessary momentum. > > When the IANA pool is depleted, regardless of whether there is a black > market, or a paid transfer policy, it is very difficult to see a > sufficient supply of IPv4 resources, for the extra-large ISP. This means > that these ISP will hit the wall first, and hit it the hardest. It is > also this group who is more able to bear the burden of working with > equipment vendors, and software developers, to push the necessary > momentum towards IPv6. Would a policy proposal that supports this model > be preferred by the community? > > Dan Alexander > Comcast Cable > ARIN AC > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Thursday, May 22, 2008 4:42 PM > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Thomas - > > Mathbox > > Sent: Thursday, May 22, 2008 12:22 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: > > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > Ted, > > > > At the risk of receiving the wrath of the PPML Gods... > > > > > X-small: 61 cents/year > > > > X-Large fee is up to a /14. Anything over a /14 is no charge. > > So, you cannot apply a single divisor that applies to all X-Large. The > > > /8 that they may also have is FREE. Most X-Large pay less than $.01 > > per IP. > > > > "...may also have is FREE..." is a reference to legacy allocations and > I was not talking about that, those are a separate issue. > > As for the penny an IP address the X-large pays, sure on the surface > that seems unfair. But, I will point out that precisely because they > are X-large, and have so many IP's already, that in a time of IPv4 > runout, they are going to be under intense pressure to both move to > IPv6, and also to justify why they have so much IPv4 tied up. > > The small low-growth organizations who have maybe a /18 tied up, and who > are experiencing maybe a 2% per year real growth in customer count, > those folks aren't going to suffer in IPv4 runout time. They will be > paying their bills, keeping people employed, keeping their customers > happy, basically being good citizens. > They will be able to sit back and weather the storm, and because they > have so little IPv4 tied up as compared to the large holders, nobody is > going to come banging on their door demanding they prove justification > for their holdings, because even if what they have has a lot of unused > numbers, the amount of unused numbering they have is so small it won't > help any of the larger well-financed consumers of IP addressing for more > than a few days of growth. > > The political and economic realities are that the X-larges are going to > bear the brunt of the costs of switchover to IPv6 - and they will also > suffer the largest customer losses, as they tell customers that they > can't support IPv4, those customers who don't want to switch (think - > all of them) will be going to the smaller providers. > > And when the large guys have ended up funding all the R&D for the > production deployment of IPv6, by then the small guys will have a > literal wealth of gear and deployment strategies to pick and choose > from, as well as be able to know all the pitfalls, AND even better, > since they really will be the last to covert over, their customers will > not be able to carry out the threat of "quitting service and finding an > ISP that will sell us IPv4" > since there won't BE any ISP's left that will sell IPv4. > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per customer, > > > because we have to carry more route entries for the same number > > > > It is a two-way street... > > > > > of customers, so I am perfectly contented with the "smaller > > allocation > > > tax" of more cents per IP per year > > > > Exactly how much of that "tax-the-poor" does your company collect? > > Other than providing a barrier to competition, how does it benefit > > your company? > > > > Naturally, our pricing has to be set according to what the other guy has > his pricing set to - that's determined by competition. > But, because we are smaller, we have much more flexibility in reducing > our internal costs than the large guy does. So we pay more for > numbering, but we can do things like using PC's running Quagga for BGP > routers instead of Junipers, and the savings more than make up for the > IP costs. (I'm not saying that we currently do this, but we have done > so in the past - and the reliability is no worse than the commercial > routers) It all has a way of working out in the end. > > Ted > > > Michael Thomas > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 2:32 PM > > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > DistributionofIPv4Resources before IPv4 Run out > > > > > > > > > Hey, whatever your smoking, I want some! > > > > > > ARIN -does- charge per IP address. I may have imbibed a number of > > > hallucinogenic substances over the years but the bill we get from > > > them every year is most definitely NOT a figment of my imagination! > > > > > > Or were you under the impression that ARIN was funded by > > Tinker Bell > > > and friends? > > > > > > In case you were, here is the ARIN fee schedule: > > > > > > http://www.arin.net/billing/fee_schedule.html > > > > > > Fees per IP address: > > > > > > X-small: 61 cents/year > > > Small: 28 cents/year > > > Medium: 6 cents/year > > > Large: 3 cents/year > > > > > > and so forth. > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per customer, > > > because we have to carry more route entries for the same number of > > > customers, so I am perfectly contented with the "smaller allocation > > > tax" of more cents per IP per year > > > > > > If you go to Costco the giant bundle of toilet paper also > > costs less > > > per roll. That's just how things work in life. > > > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > > Sent: Thursday, May 22, 2008 11:04 AM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > > > > Ip do have value, as any business using the web to generate a > > > > revenue stream can tell you. If Arin charged per ip, I doubt we > > > > would be > > > > running out of IP' addresses any time in the near future. > > > You would > > > > see a lot of IP addresses being returned that were not in use, at > > > > the very least. > > > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > > > > Thanks, > > > > Charlie Sawyer > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > > Sent: Thursday, May 22, 2008 12:25 PM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > of IPv4Resources before IPv4 Run out > > > > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > > address distribution, which this proposal is trying to address. > > > > > > > > However, I think that while the moral is a Good Thing, > > there is no > > > > practical way to mandate it. > > > > > > > > If this proposal were to be supported I would ask that the author > > > > modify it so that at the least, there would be an automatic > > > > expiration to this. > > > > > > > > The cold hard fact of the matter is that ANY isp or other "small > > > > or Very Small" organization that is NOT requesting IP addressing > > > > at this time to meet their projected future needs, is likely to > > > > get shafted when IPv4 runs out. > > > > > > > > On the day of IPv4 runout, if an ISP or organization does > > not have a > > > > supply of IPv4 to carry them forward for the immediate > > future, due > > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > > > Do we really want network administrators who aren't paying > > > > attention to the gas guage to be driving the Internet into > > > the future? > > > > > > > > Ted > > > > > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > > To: arin-ppml at arin.net > > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution of > > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > > the ARIN Internet Resource Policy Evaluation Process, > > the proposal > > > > > is being posted to the ARIN Public Policy Mailing List > > (PPML) and > > > > > being placed on ARIN's website. > > > > > > > > > > The ARIN Advisory Council (AC) will review this > > proposal at their > > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > > > 2. Postpone their decision regarding the proposal > > until the > > > > > next regularly scheduled AC meeting in order to work with the > > > > > author. The AC will work with the author to clarify, combine or > > > > > divide the proposal. At their following meeting the AC > > will accept > > > > > or not accept the proposal. > > > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > > proposal, the AC will explain their decision via the PPML. If a > > > > > proposal is not accepted, then the author may elect to use the > > > > > petition process to advance their proposal. If the > > author elects > > > > > not to petition or the petition fails, then the > > proposal will be > > > > > closed. > > > > > > > > > > The AC will assign shepherds in the near future. ARIN > > will provide > > > > > the names of the shepherds to the community via the PPML. > > > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > > 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. > > > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > > can be found > > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > > > Mailing list subscription information can be found at: > > > > > http://www.arin.net/mailing_lists/ > > > > > > > > > > Regards, > > > > > > > > > > Member Services > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > ## * ## > > > > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > > before IPv4 Run out > > > > > > > > > > Author: Michael K. Smith > > > > > > > > > > Proposal Version: 1 > > > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > > > Proposal type: new > > > > > > > > > > Policy term: permanent > > > > > > > > > > Policy statement: > > > > > > > > > > Upon receipt of the last allocation of IPv4 address > > space to ARIN > > > > > from IANA, ARIN will reserve address space within the allocated > > > > > block for Organizations within the defined ARIN Organizational > > > > > Size determinations (Extra Small, Small, Large, Extra > > Large) based > > > > > upon the utilization percentages for each group > > gathered from the > > > > > statistics of the last two IANA allocations to ARIN. > > In order to > > > > > make the allocation percentages mathematically feasible, the > > > > > percentages will be rounded to the closest whole number and, > > > > > subsequently, the the closest bit boundary for assignment the > > > > > maximum allocation size for the Organization size as defined by > > > > > ARIN. > > > > > > > > > > Once the final IANA allocation is received, ARIN will > > publish the > > > > > allocation percentages that will be used for the final > > allocation > > > > > to the PPML and ARIN website with the necessary documentation > > > > > supporting the assignment of percentages. > > > > > > > > > > Rationale: > > > > > > > > > > Description: > > > > > > > > > > This policy is designed to allow Organizations of the various > > > > > defined sizes to continue to receive address > > allocations from the > > > > > last available space and is slanted towards ensuring that > > > > > organizations within the Large, Small and Extra Small > > groups (and > > > > > more specifically, the Small and Extra Small groups) > > are able to > > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > > allocate such space. Given the statistics below, it is likely > > > > > that Extra Large Organizations would get most or all of > > the last > > > > > remaining space because given the amount they have been > > allocated > > > > > to date. This policy would help ensure that other > > Organizations > > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > > > > Example: > > > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > > statistics are generated from IP allocations from 2006 > > and 2007). > > > > > This policy would require statistics to be limited to > > the previous > > > > > 2 IANA allocations to ARIN.) > > > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > > > Extra Large: 83.11% > > > > > Large: 6.75% > > > > > Small: 9.00% > > > > > Extra Small: 1.14% > > > > > > > > > > With this example, ARIN would reserve address space in > > the final > > > > > IANA allocation according to those percentages, to the > > extent that > > > > > it is mathematically possible within the existing > > range. In order > > > > > to make the math work, rounding would give us: > > > > > > > > > > Extra Large: 83% > > > > > Large: 7% > > > > > Small: 9% > > > > > Extra Small: 1% > > > > > > > > > > Who is affected: > > > > > > > > > > All ARIN Members will be affected by this policy. I > > assume that > > > > > smaller providers will benefit from having some space > > available to > > > > > them beyond where they would be with an organic > > allocation model, > > > > > and the Extra Large Organizations would experience some pain > > > > > because, using the model above, they would be excluded > > from being > > > > > allocated 17% of the remaining space, even if they had > > all of the > > > > > necessary justifications for receiving allocations from within > > > > > that space. > > > > > > > > > > Policy Enforcement: > > > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > > allocations stay within the published percentages. > > > > > > > > > > Financial and Liability Implications: > > > > > > > > > > Financially, there may be additional resources required by ARIN > > > > > Staff to allocate resources using this model. These resources > > > > > might include application development, staff training > > and tracking > > > > > of allocations based upon the model. > > > > > > > > > > ARIN may have legal liability should Organizations that were > > > > > denied space according to the model decide to contest > > the legality > > > > > of the policy in court. > > > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > > allocation (roughly 2011). > > > > > > > > > > _______________________________________________ > > > > > PPML > > > > > You are receiving this message because you are > > subscribed to the > > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe > > > > > or manage your mailing list subscription at: > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > Please contact the ARIN Member Services Help Desk at > > > > > 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. From nday at softlayer.com Thu May 22 21:53:09 2008 From: nday at softlayer.com (Nathan Day) Date: Thu, 22 May 2008 20:53:09 -0500 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resourcesbefore IPv4 Run out In-Reply-To: <17838240D9A5544AAA5FF95F8D520316040989A3@ad-exh01.adhost.lan> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk><997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> <17838240D9A5544AAA5FF95F8D520316040989A3@ad-exh01.adhost.lan> Message-ID: <4E9A1234BB36494E97682CEC3958C0340611045D@slmail01.softlayer.local> Michael, I do agree with trying to make the most efficient use of the ipv4 resources as we approach the end of this limited resource and I?m glad people are discussing it. You don't try to hide that this proposal is for the benefit of smaller orgs at the expense of the larger orgs. I just don't understand what qualities a smaller org has that makes it more deserving of ipv4 resources than a larger org. Are smaller orgs better custodians of ipv4 resources than larger orgs based on purely their size? The current policies are intended to balance need and efficient use. I would prefer to see the last blocks of ipv4 space allocated based on need and demonstrated efficient use of previous allocations. Nathan Day SoftLayer.com -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith - Adhost Sent: Thursday, May 22, 2008 7:22 PM To: Alexander, Daniel; arin-ppml at arin.net Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resourcesbefore IPv4 Run out Hello Daniel: I'm sure you can guess my position, but the idea that smaller organizations would be more adversely affected at the point of depletion was part of my rationale behind submitting a policy that was tilted at benefitting those organizations. I had thought through several different models for distribution, including flat percentages based upon org size, a model based upon only allocating in halves the last IANA allocation (if a /14 is left, you can't allocate the /14 to one org, only half of it, then half the remaining, etc. But, that got ugly fast), and reserving space based upon the allocation size for the groups (x number of /20's, x number of /22's, etc.). Using the percentages from previous allocations seemed the most equitable and, thus, the most likely to be palatable to orgs of every size, provided the bigger concept of helping the smaller orgs was accepted by the community. If anyone has a better model I am all ears. Regards, Mike > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Alexander, Daniel > Sent: Thursday, May 22, 2008 4:13 PM > To: Ted Mittelstaedt; arin-ppml at arin.net > Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources > before IPv4 Run out > > Ted, > > You made some points in your reply that I think echo the intent of > Michael's proposal. Aside from how it tries to get there, I am curious > to hear from the community on its thoughts of the rationale. > > Who likes the idea of a policy to handle an IANA depleted situation, > where the smaller organizations are less effected, in order to buy them > time, while the larger organizations are forced towards IPv6. It is the > largest IP consumers who will drive the vendors, and develop the market > for IPv6 enabled equipment. It is the smallest organizations who need to > remain on IPv4 until the shift has gained the necessary momentum. > > When the IANA pool is depleted, regardless of whether there is a black > market, or a paid transfer policy, it is very difficult to see a > sufficient supply of IPv4 resources, for the extra-large ISP. This means > that these ISP will hit the wall first, and hit it the hardest. It is > also this group who is more able to bear the burden of working with > equipment vendors, and software developers, to push the necessary > momentum towards IPv6. Would a policy proposal that supports this model > be preferred by the community? > > Dan Alexander > Comcast Cable > ARIN AC > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Thursday, May 22, 2008 4:42 PM > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Thomas - > > Mathbox > > Sent: Thursday, May 22, 2008 12:22 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: > > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > Ted, > > > > At the risk of receiving the wrath of the PPML Gods... > > > > > X-small: 61 cents/year > > > > X-Large fee is up to a /14. Anything over a /14 is no charge. > > So, you cannot apply a single divisor that applies to all X-Large. The > > > /8 that they may also have is FREE. Most X-Large pay less than $.01 > > per IP. > > > > "...may also have is FREE..." is a reference to legacy allocations and > I was not talking about that, those are a separate issue. > > As for the penny an IP address the X-large pays, sure on the surface > that seems unfair. But, I will point out that precisely because they > are X-large, and have so many IP's already, that in a time of IPv4 > runout, they are going to be under intense pressure to both move to > IPv6, and also to justify why they have so much IPv4 tied up. > > The small low-growth organizations who have maybe a /18 tied up, and who > are experiencing maybe a 2% per year real growth in customer count, > those folks aren't going to suffer in IPv4 runout time. They will be > paying their bills, keeping people employed, keeping their customers > happy, basically being good citizens. > They will be able to sit back and weather the storm, and because they > have so little IPv4 tied up as compared to the large holders, nobody is > going to come banging on their door demanding they prove justification > for their holdings, because even if what they have has a lot of unused > numbers, the amount of unused numbering they have is so small it won't > help any of the larger well-financed consumers of IP addressing for more > than a few days of growth. > > The political and economic realities are that the X-larges are going to > bear the brunt of the costs of switchover to IPv6 - and they will also > suffer the largest customer losses, as they tell customers that they > can't support IPv4, those customers who don't want to switch (think - > all of them) will be going to the smaller providers. > > And when the large guys have ended up funding all the R&D for the > production deployment of IPv6, by then the small guys will have a > literal wealth of gear and deployment strategies to pick and choose > from, as well as be able to know all the pitfalls, AND even better, > since they really will be the last to covert over, their customers will > not be able to carry out the threat of "quitting service and finding an > ISP that will sell us IPv4" > since there won't BE any ISP's left that will sell IPv4. > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per customer, > > > because we have to carry more route entries for the same number > > > > It is a two-way street... > > > > > of customers, so I am perfectly contented with the "smaller > > allocation > > > tax" of more cents per IP per year > > > > Exactly how much of that "tax-the-poor" does your company collect? > > Other than providing a barrier to competition, how does it benefit > > your company? > > > > Naturally, our pricing has to be set according to what the other guy has > his pricing set to - that's determined by competition. > But, because we are smaller, we have much more flexibility in reducing > our internal costs than the large guy does. So we pay more for > numbering, but we can do things like using PC's running Quagga for BGP > routers instead of Junipers, and the savings more than make up for the > IP costs. (I'm not saying that we currently do this, but we have done > so in the past - and the reliability is no worse than the commercial > routers) It all has a way of working out in the end. > > Ted > > > Michael Thomas > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 2:32 PM > > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > DistributionofIPv4Resources before IPv4 Run out > > > > > > > > > Hey, whatever your smoking, I want some! > > > > > > ARIN -does- charge per IP address. I may have imbibed a number of > > > hallucinogenic substances over the years but the bill we get from > > > them every year is most definitely NOT a figment of my imagination! > > > > > > Or were you under the impression that ARIN was funded by > > Tinker Bell > > > and friends? > > > > > > In case you were, here is the ARIN fee schedule: > > > > > > http://www.arin.net/billing/fee_schedule.html > > > > > > Fees per IP address: > > > > > > X-small: 61 cents/year > > > Small: 28 cents/year > > > Medium: 6 cents/year > > > Large: 3 cents/year > > > > > > and so forth. > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per customer, > > > because we have to carry more route entries for the same number of > > > customers, so I am perfectly contented with the "smaller allocation > > > tax" of more cents per IP per year > > > > > > If you go to Costco the giant bundle of toilet paper also > > costs less > > > per roll. That's just how things work in life. > > > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > > Sent: Thursday, May 22, 2008 11:04 AM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > > > > Ip do have value, as any business using the web to generate a > > > > revenue stream can tell you. If Arin charged per ip, I doubt we > > > > would be > > > > running out of IP' addresses any time in the near future. > > > You would > > > > see a lot of IP addresses being returned that were not in use, at > > > > the very least. > > > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > > > > Thanks, > > > > Charlie Sawyer > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > > Sent: Thursday, May 22, 2008 12:25 PM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > of IPv4Resources before IPv4 Run out > > > > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > > address distribution, which this proposal is trying to address. > > > > > > > > However, I think that while the moral is a Good Thing, > > there is no > > > > practical way to mandate it. > > > > > > > > If this proposal were to be supported I would ask that the author > > > > modify it so that at the least, there would be an automatic > > > > expiration to this. > > > > > > > > The cold hard fact of the matter is that ANY isp or other "small > > > > or Very Small" organization that is NOT requesting IP addressing > > > > at this time to meet their projected future needs, is likely to > > > > get shafted when IPv4 runs out. > > > > > > > > On the day of IPv4 runout, if an ISP or organization does > > not have a > > > > supply of IPv4 to carry them forward for the immediate > > future, due > > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > > > Do we really want network administrators who aren't paying > > > > attention to the gas guage to be driving the Internet into > > > the future? > > > > > > > > Ted > > > > > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > > To: arin-ppml at arin.net > > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution of > > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > > the ARIN Internet Resource Policy Evaluation Process, > > the proposal > > > > > is being posted to the ARIN Public Policy Mailing List > > (PPML) and > > > > > being placed on ARIN's website. > > > > > > > > > > The ARIN Advisory Council (AC) will review this > > proposal at their > > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > > > 2. Postpone their decision regarding the proposal > > until the > > > > > next regularly scheduled AC meeting in order to work with the > > > > > author. The AC will work with the author to clarify, combine or > > > > > divide the proposal. At their following meeting the AC > > will accept > > > > > or not accept the proposal. > > > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > > proposal, the AC will explain their decision via the PPML. If a > > > > > proposal is not accepted, then the author may elect to use the > > > > > petition process to advance their proposal. If the > > author elects > > > > > not to petition or the petition fails, then the > > proposal will be > > > > > closed. > > > > > > > > > > The AC will assign shepherds in the near future. ARIN > > will provide > > > > > the names of the shepherds to the community via the PPML. > > > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > > 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. > > > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > > can be found > > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > > > Mailing list subscription information can be found at: > > > > > http://www.arin.net/mailing_lists/ > > > > > > > > > > Regards, > > > > > > > > > > Member Services > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > ## * ## > > > > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > > before IPv4 Run out > > > > > > > > > > Author: Michael K. Smith > > > > > > > > > > Proposal Version: 1 > > > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > > > Proposal type: new > > > > > > > > > > Policy term: permanent > > > > > > > > > > Policy statement: > > > > > > > > > > Upon receipt of the last allocation of IPv4 address > > space to ARIN > > > > > from IANA, ARIN will reserve address space within the allocated > > > > > block for Organizations within the defined ARIN Organizational > > > > > Size determinations (Extra Small, Small, Large, Extra > > Large) based > > > > > upon the utilization percentages for each group > > gathered from the > > > > > statistics of the last two IANA allocations to ARIN. > > In order to > > > > > make the allocation percentages mathematically feasible, the > > > > > percentages will be rounded to the closest whole number and, > > > > > subsequently, the the closest bit boundary for assignment the > > > > > maximum allocation size for the Organization size as defined by > > > > > ARIN. > > > > > > > > > > Once the final IANA allocation is received, ARIN will > > publish the > > > > > allocation percentages that will be used for the final > > allocation > > > > > to the PPML and ARIN website with the necessary documentation > > > > > supporting the assignment of percentages. > > > > > > > > > > Rationale: > > > > > > > > > > Description: > > > > > > > > > > This policy is designed to allow Organizations of the various > > > > > defined sizes to continue to receive address > > allocations from the > > > > > last available space and is slanted towards ensuring that > > > > > organizations within the Large, Small and Extra Small > > groups (and > > > > > more specifically, the Small and Extra Small groups) > > are able to > > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > > allocate such space. Given the statistics below, it is likely > > > > > that Extra Large Organizations would get most or all of > > the last > > > > > remaining space because given the amount they have been > > allocated > > > > > to date. This policy would help ensure that other > > Organizations > > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > > > > Example: > > > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > > statistics are generated from IP allocations from 2006 > > and 2007). > > > > > This policy would require statistics to be limited to > > the previous > > > > > 2 IANA allocations to ARIN.) > > > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > > > Extra Large: 83.11% > > > > > Large: 6.75% > > > > > Small: 9.00% > > > > > Extra Small: 1.14% > > > > > > > > > > With this example, ARIN would reserve address space in > > the final > > > > > IANA allocation according to those percentages, to the > > extent that > > > > > it is mathematically possible within the existing > > range. In order > > > > > to make the math work, rounding would give us: > > > > > > > > > > Extra Large: 83% > > > > > Large: 7% > > > > > Small: 9% > > > > > Extra Small: 1% > > > > > > > > > > Who is affected: > > > > > > > > > > All ARIN Members will be affected by this policy. I > > assume that > > > > > smaller providers will benefit from having some space > > available to > > > > > them beyond where they would be with an organic > > allocation model, > > > > > and the Extra Large Organizations would experience some pain > > > > > because, using the model above, they would be excluded > > from being > > > > > allocated 17% of the remaining space, even if they had > > all of the > > > > > necessary justifications for receiving allocations from within > > > > > that space. > > > > > > > > > > Policy Enforcement: > > > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > > allocations stay within the published percentages. > > > > > > > > > > Financial and Liability Implications: > > > > > > > > > > Financially, there may be additional resources required by ARIN > > > > > Staff to allocate resources using this model. These resources > > > > > might include application development, staff training > > and tracking > > > > > of allocations based upon the model. > > > > > > > > > > ARIN may have legal liability should Organizations that were > > > > > denied space according to the model decide to contest > > the legality > > > > > of the policy in court. > > > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > > allocation (roughly 2011). > > > > > > > > > > _______________________________________________ > > > > > PPML > > > > > You are receiving this message because you are > > subscribed to the > > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe > > > > > or manage your mailing list subscription at: > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > Please contact the ARIN Member Services Help Desk at > > > > > 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. The contents of this email message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust for the sole purpose of delivery to the intended recipient. If you have received this transmission in error; any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and delete this message and all associated attachments. From kkargel at polartel.com Fri May 23 09:26:46 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 23 May 2008 08:26:46 -0500 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk> <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A1079D@mail> How about this then, allocating the last of IPV4 using the "halfway there" algorythm, Whereby no single allocation can be made that is larger than half of the remaining pool. Granted the extra-large consumer will hit the wall first this way, but it would ensure that there wasn't a land grab by a greedy rich guy to take the last ip in the world. I haven't thought this through, so it is not in the form of a proposal, but I think the idea has some merits. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Thursday, May 22, 2008 6:13 PM To: Ted Mittelstaedt; arin-ppml at arin.net Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out Ted, You made some points in your reply that I think echo the intent of Michael's proposal. Aside from how it tries to get there, I am curious to hear from the community on its thoughts of the rationale. Who likes the idea of a policy to handle an IANA depleted situation, where the smaller organizations are less effected, in order to buy them time, while the larger organizations are forced towards IPv6. It is the largest IP consumers who will drive the vendors, and develop the market for IPv6 enabled equipment. It is the smallest organizations who need to remain on IPv4 until the shift has gained the necessary momentum. When the IANA pool is depleted, regardless of whether there is a black market, or a paid transfer policy, it is very difficult to see a sufficient supply of IPv4 resources, for the extra-large ISP. This means that these ISP will hit the wall first, and hit it the hardest. It is also this group who is more able to bear the burden of working with equipment vendors, and software developers, to push the necessary momentum towards IPv6. Would a policy proposal that supports this model be preferred by the community? Dan Alexander Comcast Cable ARIN AC -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Thursday, May 22, 2008 4:42 PM To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Thomas - > Mathbox > Sent: Thursday, May 22, 2008 12:22 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: > EquitableDistributionofIPv4Resources before IPv4 Run out > > > Ted, > > At the risk of receiving the wrath of the PPML Gods... > > > X-small: 61 cents/year > > X-Large fee is up to a /14. Anything over a /14 is no charge. > So, you cannot apply a single divisor that applies to all X-Large. The > /8 that they may also have is FREE. Most X-Large pay less than $.01 > per IP. > "...may also have is FREE..." is a reference to legacy allocations and I was not talking about that, those are a separate issue. As for the penny an IP address the X-large pays, sure on the surface that seems unfair. But, I will point out that precisely because they are X-large, and have so many IP's already, that in a time of IPv4 runout, they are going to be under intense pressure to both move to IPv6, and also to justify why they have so much IPv4 tied up. The small low-growth organizations who have maybe a /18 tied up, and who are experiencing maybe a 2% per year real growth in customer count, those folks aren't going to suffer in IPv4 runout time. They will be paying their bills, keeping people employed, keeping their customers happy, basically being good citizens. They will be able to sit back and weather the storm, and because they have so little IPv4 tied up as compared to the large holders, nobody is going to come banging on their door demanding they prove justification for their holdings, because even if what they have has a lot of unused numbers, the amount of unused numbering they have is so small it won't help any of the larger well-financed consumers of IP addressing for more than a few days of growth. The political and economic realities are that the X-larges are going to bear the brunt of the costs of switchover to IPv6 - and they will also suffer the largest customer losses, as they tell customers that they can't support IPv4, those customers who don't want to switch (think - all of them) will be going to the smaller providers. And when the large guys have ended up funding all the R&D for the production deployment of IPv6, by then the small guys will have a literal wealth of gear and deployment strategies to pick and choose from, as well as be able to know all the pitfalls, AND even better, since they really will be the last to covert over, their customers will not be able to carry out the threat of "quitting service and finding an ISP that will sell us IPv4" since there won't BE any ISP's left that will sell IPv4. > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number > > It is a two-way street... > > > of customers, so I am perfectly contented with the "smaller > allocation > > tax" of more cents per IP per year > > Exactly how much of that "tax-the-poor" does your company collect? > Other than providing a barrier to competition, how does it benefit > your company? > Naturally, our pricing has to be set according to what the other guy has his pricing set to - that's determined by competition. But, because we are smaller, we have much more flexibility in reducing our internal costs than the large guy does. So we pay more for numbering, but we can do things like using PC's running Quagga for BGP routers instead of Junipers, and the savings more than make up for the IP costs. (I'm not saying that we currently do this, but we have done so in the past - and the reliability is no worse than the commercial routers) It all has a way of working out in the end. Ted > Michael Thomas > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 2:32 PM > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > DistributionofIPv4Resources before IPv4 Run out > > > > > > Hey, whatever your smoking, I want some! > > > > ARIN -does- charge per IP address. I may have imbibed a number of > > hallucinogenic substances over the years but the bill we get from > > them every year is most definitely NOT a figment of my imagination! > > > > Or were you under the impression that ARIN was funded by > Tinker Bell > > and friends? > > > > In case you were, here is the ARIN fee schedule: > > > > http://www.arin.net/billing/fee_schedule.html > > > > Fees per IP address: > > > > X-small: 61 cents/year > > Small: 28 cents/year > > Medium: 6 cents/year > > Large: 3 cents/year > > > > and so forth. > > > > The fact of the matter is that on a per-IP basis, the smaller > > allocations cost everyone on the Internet more money per customer, > > because we have to carry more route entries for the same number of > > customers, so I am perfectly contented with the "smaller allocation > > tax" of more cents per IP per year > > > > If you go to Costco the giant bundle of toilet paper also > costs less > > per roll. That's just how things work in life. > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > Ted > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > Sent: Thursday, May 22, 2008 11:04 AM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > Ip do have value, as any business using the web to generate a > > > revenue stream can tell you. If Arin charged per ip, I doubt we > > > would be > > > running out of IP' addresses any time in the near future. > > You would > > > see a lot of IP addresses being returned that were not in use, at > > > the very least. > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > Thanks, > > > Charlie Sawyer > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 12:25 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > of IPv4Resources before IPv4 Run out > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > address distribution, which this proposal is trying to address. > > > > > > However, I think that while the moral is a Good Thing, > there is no > > > practical way to mandate it. > > > > > > If this proposal were to be supported I would ask that the author > > > modify it so that at the least, there would be an automatic > > > expiration to this. > > > > > > The cold hard fact of the matter is that ANY isp or other "small > > > or Very Small" organization that is NOT requesting IP addressing > > > at this time to meet their projected future needs, is likely to > > > get shafted when IPv4 runs out. > > > > > > On the day of IPv4 runout, if an ISP or organization does > not have a > > > supply of IPv4 to carry them forward for the immediate > future, due > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > Do we really want network administrators who aren't paying > > > attention to the gas guage to be driving the Internet into > > the future? > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > To: arin-ppml at arin.net > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution of > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > the ARIN Internet Resource Policy Evaluation Process, > the proposal > > > > is being posted to the ARIN Public Policy Mailing List > (PPML) and > > > > being placed on ARIN's website. > > > > > > > > The ARIN Advisory Council (AC) will review this > proposal at their > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > 2. Postpone their decision regarding the proposal > until the > > > > next regularly scheduled AC meeting in order to work with the > > > > author. The AC will work with the author to clarify, combine or > > > > divide the proposal. At their following meeting the AC > will accept > > > > or not accept the proposal. > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > proposal, the AC will explain their decision via the PPML. If a > > > > proposal is not accepted, then the author may elect to use the > > > > petition process to advance their proposal. If the > author elects > > > > not to petition or the petition fails, then the > proposal will be > > > > closed. > > > > > > > > The AC will assign shepherds in the near future. ARIN > will provide > > > > the names of the shepherds to the community via the PPML. > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > 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. > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > can be found > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > Mailing list subscription information can be found at: > > > > http://www.arin.net/mailing_lists/ > > > > > > > > Regards, > > > > > > > > Member Services > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > ## * ## > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > before IPv4 Run out > > > > > > > > Author: Michael K. Smith > > > > > > > > Proposal Version: 1 > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > Proposal type: new > > > > > > > > Policy term: permanent > > > > > > > > Policy statement: > > > > > > > > Upon receipt of the last allocation of IPv4 address > space to ARIN > > > > from IANA, ARIN will reserve address space within the allocated > > > > block for Organizations within the defined ARIN Organizational > > > > Size determinations (Extra Small, Small, Large, Extra > Large) based > > > > upon the utilization percentages for each group > gathered from the > > > > statistics of the last two IANA allocations to ARIN. > In order to > > > > make the allocation percentages mathematically feasible, the > > > > percentages will be rounded to the closest whole number and, > > > > subsequently, the the closest bit boundary for assignment the > > > > maximum allocation size for the Organization size as defined by > > > > ARIN. > > > > > > > > Once the final IANA allocation is received, ARIN will > publish the > > > > allocation percentages that will be used for the final > allocation > > > > to the PPML and ARIN website with the necessary documentation > > > > supporting the assignment of percentages. > > > > > > > > Rationale: > > > > > > > > Description: > > > > > > > > This policy is designed to allow Organizations of the various > > > > defined sizes to continue to receive address > allocations from the > > > > last available space and is slanted towards ensuring that > > > > organizations within the Large, Small and Extra Small > groups (and > > > > more specifically, the Small and Extra Small groups) > are able to > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > allocate such space. Given the statistics below, it is likely > > > > that Extra Large Organizations would get most or all of > the last > > > > remaining space because given the amount they have been > allocated > > > > to date. This policy would help ensure that other > Organizations > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > Example: > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > statistics are generated from IP allocations from 2006 > and 2007). > > > > This policy would require statistics to be limited to > the previous > > > > 2 IANA allocations to ARIN.) > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > Extra Large: 83.11% > > > > Large: 6.75% > > > > Small: 9.00% > > > > Extra Small: 1.14% > > > > > > > > With this example, ARIN would reserve address space in > the final > > > > IANA allocation according to those percentages, to the > extent that > > > > it is mathematically possible within the existing > range. In order > > > > to make the math work, rounding would give us: > > > > > > > > Extra Large: 83% > > > > Large: 7% > > > > Small: 9% > > > > Extra Small: 1% > > > > > > > > Who is affected: > > > > > > > > All ARIN Members will be affected by this policy. I > assume that > > > > smaller providers will benefit from having some space > available to > > > > them beyond where they would be with an organic > allocation model, > > > > and the Extra Large Organizations would experience some pain > > > > because, using the model above, they would be excluded > from being > > > > allocated 17% of the remaining space, even if they had > all of the > > > > necessary justifications for receiving allocations from within > > > > that space. > > > > > > > > Policy Enforcement: > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > allocations stay within the published percentages. > > > > > > > > Financial and Liability Implications: > > > > > > > > Financially, there may be additional resources required by ARIN > > > > Staff to allocate resources using this model. These resources > > > > might include application development, staff training > and tracking > > > > of allocations based upon the model. > > > > > > > > ARIN may have legal liability should Organizations that were > > > > denied space according to the model decide to contest > the legality > > > > of the policy in court. > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > allocation (roughly 2011). > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are > subscribed to the > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe > > > > or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From tme at multicasttech.com Fri May 23 10:31:30 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 23 May 2008 10:31:30 -0400 Subject: [arin-ppml] FW: Policy Proposal: Equitable Distribution ofIPv4Resources before IPv4 Run out In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB409F7C8FC@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB409F7C8FC@CL-S-EX-1.stanleyassociates.com> Message-ID: <09067670-EBB7-413D-B58F-CC37C268BD93@multicasttech.com> On May 22, 2008, at 10:44 AM, Howard, W. Lee wrote: >>> If you were to prohibit allocations to extralarge ISPs, all >> you would >>> be doing is preventing small companies from using the ISP of their >>> choice, effectively forcing them to use a small ISP. There >> are many >>> good things about small ISPs (I've worked at a couple), but >> they can't >>> meet all needs. >> >> It is also not as if large companies cannot set up or make >> alliances with small companies to get around these sorts of >> rules. Anyone with any experience with US SIBR contracting s/SIBR/SBIR/ >> >> will know what I mean. > > For those of us who don't have experience with those letters, could > you explain what you mean? > Do you mean that such alliances are important for the development > of the Internet? > No. If you deny large companies allocations, just because they are large, some will try and get around the rules. This can be done in many ways. Companies can set up front companies, fund small companies and then acquire them just after they get allocations, have employees set up subsidiaries that appear independent but aren't, etc., etc. As an illustration, various governments in the USA have set-asides and other mechanisms to fund small companies (the SBIR is one), minority owned companies, local companies, etc. It doesn't take much experience with government contracting to realize that much of the set-aside money is not really going to the people it is intended to be going to, because of the same sorts of tricks. And, at least with the Federal government, there is the force of law behind the contracting mechanisms. I do not believe that ARIN has the same sorts of investigatory powers. So, if ARIN formally prohibited "allocations to extralarge ISPs," I don't think it would work. I thus could not support any such proposal. Regards Marshall P.S. This is not to say one way or the other that set-aside government programs are useless or should be scrapped. That is a different argument. > Thanks, > Lee > >> >> Regards >> Marshall >> >> >>> >>> >>> IMHO. >>> >>> Lee >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed >> to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact the ARIN Member Services Help Desk at >> info at arin.net if >>> you experience any issues. >> >> From sleibrand at internap.com Fri May 23 11:30:18 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 23 May 2008 08:30:18 -0700 Subject: [arin-ppml] FW: Policy Proposal: Equitable Distribution ofIPv4Resources before IPv4 Run out In-Reply-To: <09067670-EBB7-413D-B58F-CC37C268BD93@multicasttech.com> References: <369EB04A0951824ABE7D8BAC67AF9BB409F7C8FC@CL-S-EX-1.stanleyassociates.com> <09067670-EBB7-413D-B58F-CC37C268BD93@multicasttech.com> Message-ID: <4836E30A.80407@internap.com> Marshall Eubanks wrote: > If you deny large companies allocations, just because they are large, > some will try and get around the rules. This can be done in many ways. > Companies can set up front companies, fund small companies and then > acquire them just after they get allocations, have employees set up > subsidiaries that appear independent but aren't, etc., etc. One other, more legitimate, response to such a restriction would be that large NSPs would require all their downstreams to get space directly from ARIN. That would result in a lot more routes in the routing table than we'd see if the same amount of space were given out as one big chunk to the provider, who in turn reassigned it to their downstreams, but only announced the aggregate. This will only apply to large address holders whose customers are large enough to qualify to get space from ARIN. That wouldn't include end-user ISPs like the cable and DSL providers, but it would include all the "tier 1" large NSPs. And since many of the end-user ISPs share common ownership with large NSPs, you can bet that if such a restriction were adopted, the NSP part of the business would immediately switch to requiring their customers to get space from ARIN to keep as much space available to individual end-users as possible. TANSTAAFL -Scott From paul at vix.com Fri May 23 12:57:57 2008 From: paul at vix.com (Paul Vixie) Date: Fri, 23 May 2008 16:57:57 +0000 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: Your message of "Fri, 23 May 2008 08:26:46 EST." <70DE64CEFD6E9A4EB7FAF3A063141066A1079D@mail> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk> <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> <70DE64CEFD6E9A4EB7FAF3A063141066A1079D@mail> Message-ID: <23072.1211561877@sa.vix.com> > How about this then, allocating the last of IPV4 using the "halfway there" > algorythm, Whereby no single allocation can be made that is larger than half > of the remaining pool. Granted the extra-large consumer will hit the wall > first this way, but it would ensure that there wasn't a land grab by a > greedy rich guy to take the last ip in the world. I haven't thought this > through, so it is not in the form of a proposal, but I think the idea has > some merits. would we call this the Zeno's Dichotomy Paradox proposal? re: http://en.wikipedia.org/wiki/Zeno's_paradoxes btw: :-) From kkargel at polartel.com Fri May 23 14:50:47 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 23 May 2008 13:50:47 -0500 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <23072.1211561877@sa.vix.com> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk> <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> <70DE64CEFD6E9A4EB7FAF3A063141066A1079D@mail> <23072.1211561877@sa.vix.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A107A3@mail> Works for me.. And then when we get to the very last IP in the world we can ebay it and throw a BIG party with the proceeds.. :) -----Original Message----- From: vixie at vix.com [mailto:vixie at vix.com] On Behalf Of Paul Vixie Sent: Friday, May 23, 2008 11:58 AM To: Kevin Kargel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources before IPv4 Run out > How about this then, allocating the last of IPV4 using the "halfway there" > algorythm, Whereby no single allocation can be made that is larger > than half of the remaining pool. Granted the extra-large consumer > will hit the wall first this way, but it would ensure that there > wasn't a land grab by a greedy rich guy to take the last ip in the > world. I haven't thought this through, so it is not in the form of a > proposal, but I think the idea has some merits. would we call this the Zeno's Dichotomy Paradox proposal? re: http://en.wikipedia.org/wiki/Zeno's_paradoxes btw: :-) From tedm at ipinc.net Fri May 23 15:18:49 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 23 May 2008 12:18:49 -0700 Subject: [arin-ppml] Policy Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out In-Reply-To: <997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> Message-ID: <5B29E603D9AC442D83FF0137377AD857@tedsdesk> > -----Original Message----- > From: Alexander, Daniel [mailto:Daniel_Alexander at cable.comcast.com] > Sent: Thursday, May 22, 2008 4:13 PM > To: Ted Mittelstaedt; arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > Ted, > > You made some points in your reply that I think echo the > intent of Michael's proposal. Aside from how it tries to get > there, I am curious to hear from the community on its > thoughts of the rationale. > > Who likes the idea of a policy to handle an IANA depleted > situation, where the smaller organizations are less effected, > in order to buy them time, while the larger organizations are > forced towards IPv6. It is the largest IP consumers who will > drive the vendors, and develop the market for IPv6 enabled > equipment. It is the smallest organizations who need to > remain on IPv4 until the shift has gained the necessary momentum. > I personally feel that a huge amount of how this shift works is going to be determined by how the X-larges approach the shift. The X-larges have the marketing dollars and muscle to set the standards - while the smalls may hate this, they are fundamentally dependent on what the X-larges do. In an ideal Internet world, the X-larges focus on selling cookie cutter solutions in bulk to people who have very simple needs, and the smalls focus on selling customized solutions to people who have support heavy, complicated needs. That way everyone makes money and all the customers get what they need. When IPv6 hits, I see one of 2 possible routes that the X-larges are going to take. The first path is to go out and spend some coin convincing customers that "everyone" is switching to IPv6 and they are going to be on an Internet backwater that will kill their productivity and turn them into paupers if they don't jump on the bandwagon. The "simple needs" customers will of course fall for this hook line and sinker. This is how the automakers sell brand new cars to people who are driving perfectly good used cars that are nowhere near needing to be replaced. It works for the automakers because most people are car-stupid but they think they know all about cars. And it would work for the customers of the X-larges too, who, like car owners, most are Internet-stupid but think they know all about the Internet. If this happens, the smalls are going to get a few of the customers smart enough to come in out of the rain, but untimately their own customers, hearing the X-large's marketing clamor, will start demading IPv6 too and the smalls will have little choice but to move forward and scrap out IPv4. However, the second path the X-larges might take is to ignore the issue completely, and allow the grass-roots bloggers and pundits to wildly speculate. The advantage to the X-larges here is that they won't have a large number of perfectly good working IPv4 customers who hear the clamor for IPv6 and start demanding their X-large drop in a tech tomorrow @ $100/hr and spend 3 hours switching their $20 a month conneciton over to IPv6. In that case the X-larges will be silently setting up new IPv4 customers with proxies and such on private networks. Their average "simple needs" customer will work fine and not know what all the fuss is about. If that happens, the smalls won't be at an immediate disadvantage since they won't have to switch over right away. But, ultimately they will be in a worse spot because you will not see the customers shift to IPv6. And herein is the bugaboo, it's the customers. The vast majority of Internet customers don't know anything about what they are buying, and if they are handed off RFC1918 IPv4 connectivity behind an IPv4<->IPv6 gateway, they will suck it down and think it is just fine. But, that would just be a disaster for the Internet if that were to become the norm - you end up with people running operating systems that are IPv6-ready, jacked into an ISP that is 90% IPv6, except for the last mile. We really, really need to do what Microsoft does, which is force the customers into IPv6 whether they want it or not. And only agreement among the X-Larges to present a united front to the customers and tell them they have to switch, is going to do it. > When the IANA pool is depleted, regardless of whether there > is a black market, or a paid transfer policy, it is very > difficult to see a sufficient supply of IPv4 resources, for > the extra-large ISP. This means that these ISP will hit the > wall first, and hit it the hardest. It is also this group who > is more able to bear the burden of working with equipment > vendors, and software developers, to push the necessary > momentum towards IPv6. Would a policy proposal that supports > this model be preferred by the community? > I would just prefer the X-larges to start telling Ma and Pa Kettle right now that they better dump their Windows 98 systems and go to Vista if they want to continue to surf the web - because 98 isn't IPv6 compliant. Ted > Dan Alexander > Comcast Cable > ARIN AC > > > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > Sent: Thursday, May 22, 2008 4:42 PM > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Michael Thomas - Mathbox > > Sent: Thursday, May 22, 2008 12:22 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: > > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > Ted, > > > > At the risk of receiving the wrath of the PPML Gods... > > > > > X-small: 61 cents/year > > > > X-Large fee is up to a /14. Anything over a /14 is no charge. > > So, you cannot apply a single divisor that applies to all > X-Large. The > > > /8 that they may also have is FREE. Most X-Large pay less than $.01 > > per IP. > > > > "...may also have is FREE..." is a reference to legacy > allocations and > I was not talking about that, those are a separate issue. > > As for the penny an IP address the X-large pays, sure on the surface > that seems unfair. But, I will point out that precisely because they > are X-large, and have so many IP's already, that in a time of IPv4 > runout, they are going to be under intense pressure to both move to > IPv6, and also to justify why they have so much IPv4 tied up. > > The small low-growth organizations who have maybe a /18 tied > up, and who > are experiencing maybe a 2% per year real growth in customer count, > those folks aren't going to suffer in IPv4 runout time. They will be > paying their bills, keeping people employed, keeping their customers > happy, basically being good citizens. > They will be able to sit back and weather the storm, and because they > have so little IPv4 tied up as compared to the large holders, > nobody is > going to come banging on their door demanding they prove justification > for their holdings, because even if what they have has a lot of unused > numbers, the amount of unused numbering they have is so small it won't > help any of the larger well-financed consumers of IP > addressing for more > than a few days of growth. > > The political and economic realities are that the X-larges > are going to > bear the brunt of the costs of switchover to IPv6 - and they will also > suffer the largest customer losses, as they tell customers that they > can't support IPv4, those customers who don't want to switch (think - > all of them) will be going to the smaller providers. > > And when the large guys have ended up funding all the R&D for the > production deployment of IPv6, by then the small guys will have a > literal wealth of gear and deployment strategies to pick and choose > from, as well as be able to know all the pitfalls, AND even better, > since they really will be the last to covert over, their > customers will > not be able to carry out the threat of "quitting service and > finding an > ISP that will sell us IPv4" > since there won't BE any ISP's left that will sell IPv4. > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per > customer, > > > because we have to carry more route entries for the same number > > > > It is a two-way street... > > > > > of customers, so I am perfectly contented with the "smaller > > allocation > > > tax" of more cents per IP per year > > > > Exactly how much of that "tax-the-poor" does your company collect? > > Other than providing a barrier to competition, how does it benefit > > your company? > > > > Naturally, our pricing has to be set according to what the > other guy has > his pricing set to - that's determined by competition. > But, because we are smaller, we have much more flexibility in reducing > our internal costs than the large guy does. So we pay more for > numbering, but we can do things like using PC's running Quagga for BGP > routers instead of Junipers, and the savings more than make up for the > IP costs. (I'm not saying that we currently do this, but we have done > so in the past - and the reliability is no worse than the commercial > routers) It all has a way of working out in the end. > > Ted > > > Michael Thomas > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 2:32 PM > > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > DistributionofIPv4Resources before IPv4 Run out > > > > > > > > > Hey, whatever your smoking, I want some! > > > > > > ARIN -does- charge per IP address. I may have imbibed a > number of > > > hallucinogenic substances over the years but the bill we get from > > > them every year is most definitely NOT a figment of my > imagination! > > > > > > Or were you under the impression that ARIN was funded by > > Tinker Bell > > > and friends? > > > > > > In case you were, here is the ARIN fee schedule: > > > > > > http://www.arin.net/billing/fee_schedule.html > > > > > > Fees per IP address: > > > > > > X-small: 61 cents/year > > > Small: 28 cents/year > > > Medium: 6 cents/year > > > Large: 3 cents/year > > > > > > and so forth. > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > allocations cost everyone on the Internet more money per > customer, > > > because we have to carry more route entries for the same > number of > > > customers, so I am perfectly contented with the "smaller > allocation > > > tax" of more cents per IP per year > > > > > > If you go to Costco the giant bundle of toilet paper also > > costs less > > > per roll. That's just how things work in life. > > > > > > But the idea that ARIN isn't charging money for IP's is > rediculous. > > > > > > > > > Ted > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > > Sent: Thursday, May 22, 2008 11:04 AM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution > > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > > > > Ip do have value, as any business using the web to generate a > > > > revenue stream can tell you. If Arin charged per ip, I > doubt we > > > > would be > > > > running out of IP' addresses any time in the near future. > > > You would > > > > see a lot of IP addresses being returned that were not > in use, at > > > > the very least. > > > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > > > > Thanks, > > > > Charlie Sawyer > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted > Mittelstaedt > > > > Sent: Thursday, May 22, 2008 12:25 PM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution > > > > of IPv4Resources before IPv4 Run out > > > > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > > address distribution, which this proposal is trying to address. > > > > > > > > However, I think that while the moral is a Good Thing, > > there is no > > > > practical way to mandate it. > > > > > > > > If this proposal were to be supported I would ask that > the author > > > > modify it so that at the least, there would be an automatic > > > > expiration to this. > > > > > > > > The cold hard fact of the matter is that ANY isp or > other "small > > > > or Very Small" organization that is NOT requesting IP > addressing > > > > at this time to meet their projected future needs, is likely to > > > > get shafted when IPv4 runs out. > > > > > > > > On the day of IPv4 runout, if an ISP or organization does > > not have a > > > > supply of IPv4 to carry them forward for the immediate > > future, due > > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > > > Do we really want network administrators who aren't paying > > > > attention to the gas guage to be driving the Internet into > > > the future? > > > > > > > > Ted > > > > > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of > Member Services > > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > > To: arin-ppml at arin.net > > > > > Subject: [arin-ppml] Policy Proposal: Equitable > Distribution of > > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > > > > ARIN received the following policy proposal. In > accordance with > > > > > the ARIN Internet Resource Policy Evaluation Process, > > the proposal > > > > > is being posted to the ARIN Public Policy Mailing List > > (PPML) and > > > > > being placed on ARIN's website. > > > > > > > > > > The ARIN Advisory Council (AC) will review this > > proposal at their > > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > > > 1. Accept the proposal as written. If the AC > accepts the > > > > > proposal, it will be posted as a formal policy > proposal to PPML > > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > > > 2. Postpone their decision regarding the proposal > > until the > > > > > next regularly scheduled AC meeting in order to work with the > > > > > author. The AC will work with the author to clarify, > combine or > > > > > divide the proposal. At their following meeting the AC > > will accept > > > > > or not accept the proposal. > > > > > > > > > > 3. Not accept the proposal. If the AC does not > accept the > > > > > proposal, the AC will explain their decision via the > PPML. If a > > > > > proposal is not accepted, then the author may elect > to use the > > > > > petition process to advance their proposal. If the > > author elects > > > > > not to petition or the petition fails, then the > > proposal will be > > > > > closed. > > > > > > > > > > The AC will assign shepherds in the near future. ARIN > > will provide > > > > > the names of the shepherds to the community via the PPML. > > > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > > 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. > > > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > > can be found > > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > > > Mailing list subscription information can be found at: > > > > > http://www.arin.net/mailing_lists/ > > > > > > > > > > Regards, > > > > > > > > > > Member Services > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > ## * ## > > > > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 > Resources > > > > > before IPv4 Run out > > > > > > > > > > Author: Michael K. Smith > > > > > > > > > > Proposal Version: 1 > > > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > > > Proposal type: new > > > > > > > > > > Policy term: permanent > > > > > > > > > > Policy statement: > > > > > > > > > > Upon receipt of the last allocation of IPv4 address > > space to ARIN > > > > > from IANA, ARIN will reserve address space within the > allocated > > > > > block for Organizations within the defined ARIN > Organizational > > > > > Size determinations (Extra Small, Small, Large, Extra > > Large) based > > > > > upon the utilization percentages for each group > > gathered from the > > > > > statistics of the last two IANA allocations to ARIN. > > In order to > > > > > make the allocation percentages mathematically feasible, the > > > > > percentages will be rounded to the closest whole number and, > > > > > subsequently, the the closest bit boundary for assignment the > > > > > maximum allocation size for the Organization size as > defined by > > > > > ARIN. > > > > > > > > > > Once the final IANA allocation is received, ARIN will > > publish the > > > > > allocation percentages that will be used for the final > > allocation > > > > > to the PPML and ARIN website with the necessary documentation > > > > > supporting the assignment of percentages. > > > > > > > > > > Rationale: > > > > > > > > > > Description: > > > > > > > > > > This policy is designed to allow Organizations of the various > > > > > defined sizes to continue to receive address > > allocations from the > > > > > last available space and is slanted towards ensuring that > > > > > organizations within the Large, Small and Extra Small > > groups (and > > > > > more specifically, the Small and Extra Small groups) > > are able to > > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > > allocate such space. Given the statistics below, it > is likely > > > > > that Extra Large Organizations would get most or all of > > the last > > > > > remaining space because given the amount they have been > > allocated > > > > > to date. This policy would help ensure that other > > Organizations > > > > > had a statistically equal opportunity to receive > space as well. > > > > > > > > > > > > > > > Example: > > > > > > > > > > Please see http://www.arin.net/statistics/index.html > (Note: the > > > > > statistics are generated from IP allocations from 2006 > > and 2007). > > > > > This policy would require statistics to be limited to > > the previous > > > > > 2 IANA allocations to ARIN.) > > > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > > > Extra Large: 83.11% > > > > > Large: 6.75% > > > > > Small: 9.00% > > > > > Extra Small: 1.14% > > > > > > > > > > With this example, ARIN would reserve address space in > > the final > > > > > IANA allocation according to those percentages, to the > > extent that > > > > > it is mathematically possible within the existing > > range. In order > > > > > to make the math work, rounding would give us: > > > > > > > > > > Extra Large: 83% > > > > > Large: 7% > > > > > Small: 9% > > > > > Extra Small: 1% > > > > > > > > > > Who is affected: > > > > > > > > > > All ARIN Members will be affected by this policy. I > > assume that > > > > > smaller providers will benefit from having some space > > available to > > > > > them beyond where they would be with an organic > > allocation model, > > > > > and the Extra Large Organizations would experience some pain > > > > > because, using the model above, they would be excluded > > from being > > > > > allocated 17% of the remaining space, even if they had > > all of the > > > > > necessary justifications for receiving allocations > from within > > > > > that space. > > > > > > > > > > Policy Enforcement: > > > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > > allocations stay within the published percentages. > > > > > > > > > > Financial and Liability Implications: > > > > > > > > > > Financially, there may be additional resources > required by ARIN > > > > > Staff to allocate resources using this model. These > resources > > > > > might include application development, staff training > > and tracking > > > > > of allocations based upon the model. > > > > > > > > > > ARIN may have legal liability should Organizations that were > > > > > denied space according to the model decide to contest > > the legality > > > > > of the policy in court. > > > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > > allocation (roughly 2011). > > > > > > > > > > _______________________________________________ > > > > > PPML > > > > > You are receiving this message because you are > > subscribed to the > > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe > > > > > or manage your mailing list subscription at: > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > Please contact the ARIN Member Services Help Desk at > > > > > 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at > > 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 the ARIN Member Services Help Desk at info at arin.net if > you experience any issues. > > From tedm at ipinc.net Fri May 23 15:29:29 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 23 May 2008 12:29:29 -0700 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4ResourcesbeforeIPv4 Run out In-Reply-To: <4E9A1234BB36494E97682CEC3958C0340611045D@slmail01.softlayer.local> Message-ID: <3CE7E94658044001A937D7B5FB336C27@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Nathan Day > Sent: Thursday, May 22, 2008 6:53 PM > To: Michael K. Smith - Adhost; arin-ppml at arin.net > Subject: Re: > [arin-ppml]PolicyProposal:EquitableDistributionofIPv4Resources > beforeIPv4 Run out > > > Michael, > > I do agree with trying to make the most efficient use of the > ipv4 resources as we approach the end of this limited > resource and I'm glad people are discussing it. > > You don't try to hide that this proposal is for the benefit > of smaller orgs at the expense of the larger orgs. I just > don't understand what qualities a smaller org has that makes > it more deserving of ipv4 resources than a larger org. Are > smaller orgs better custodians of ipv4 resources than larger > orgs based on purely their size? > It has nothing to do with that. It has everything to do with innovation and continuting to grow the Internet. If you look at EVERY major application today that is popular, and generating scads of money for the large orgs, you will find if you look at it's history that it DID NOT originate in a large org. It originated in a small org. In the tech industry, SOP is that the small orgs dream up the new ideas, the large orgs then copy the successful ones and market the shoit out of them, making millions doing so. And the cost to the larg orgs for this is trivial - maybe 2% fewer customers than they would otherwise have. If the large orgs wanted to stomp the small orgs out of existence they could do so VERY easily. But if they did this they would sacrifice their own future, because they would kill the golden geese that are out there laying eggs - which the large orgs are then picking up. If you look at industries - like the soft drink industry - where the large companies were allowed to stomp the small makers out of business, you find extremely static markets that are very vulnerable. Thus, the loss of the soft drink market to Starbucks and it's ilk. Which, if the soft drink market did have the golden geese out there laying eggs, would never have happened. It is too late for the soft drink market to recover from this, their loss to the coffee people will continue - but the large orgs in the Tech industry are going to make sure this doesen't happen in the Internet business. Ted > The current policies are intended to balance need and > efficient use. I would prefer to see the last blocks of ipv4 > space allocated based on need and demonstrated efficient use > of previous allocations. > > Nathan Day > SoftLayer.com > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. > Smith - Adhost > Sent: Thursday, May 22, 2008 7:22 PM > To: Alexander, Daniel; arin-ppml at arin.net > Subject: Re: [arin-ppml] > PolicyProposal:EquitableDistributionofIPv4Resourcesbefore IPv4 Run out > > Hello Daniel: > > I'm sure you can guess my position, but the idea that smaller > organizations would be more adversely affected at the point > of depletion was part of my rationale behind submitting a > policy that was tilted at benefitting those organizations. > > I had thought through several different models for > distribution, including flat percentages based upon org size, > a model based upon only allocating in halves the last IANA > allocation (if a /14 is left, you can't allocate the /14 to > one org, only half of it, then half the remaining, etc. But, > that got ugly fast), and reserving space based upon the > allocation size for the groups (x number of /20's, x number > of /22's, etc.). Using the percentages from previous > allocations seemed the most equitable and, thus, the most > likely to be palatable to orgs of every size, provided the > bigger concept of helping the smaller orgs was accepted by > the community. If anyone has a better model I am all ears. > > Regards, > > Mike > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Alexander, Daniel > > Sent: Thursday, May 22, 2008 4:13 PM > > To: Ted Mittelstaedt; arin-ppml at arin.net > > Subject: Re: [arin-ppml] > > PolicyProposal:EquitableDistributionofIPv4Resources > > before IPv4 Run out > > > > Ted, > > > > You made some points in your reply that I think echo the intent of > > Michael's proposal. Aside from how it tries to get there, I > am curious > > to hear from the community on its thoughts of the rationale. > > > > Who likes the idea of a policy to handle an IANA depleted > situation, > > where the smaller organizations are less effected, in order to buy > > them time, while the larger organizations are forced > towards IPv6. It > > is the largest IP consumers who will drive the vendors, and develop > > the market for IPv6 enabled equipment. It is the smallest > > organizations who need to remain on IPv4 until the shift has gained > > the necessary momentum. > > > > When the IANA pool is depleted, regardless of whether there > is a black > > market, or a paid transfer policy, it is very difficult to see a > > sufficient supply of IPv4 resources, for the extra-large ISP. This > > means that these ISP will hit the wall first, and hit it > the hardest. > > It is also this group who is more able to bear the burden > of working > > with equipment vendors, and software developers, to push > the necessary > > momentum towards IPv6. Would a policy proposal that supports this > > model be preferred by the community? > > > > Dan Alexander > > Comcast Cable > > ARIN AC > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 4:42 PM > > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy > > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > > On Behalf Of Michael Thomas - Mathbox > > > Sent: Thursday, May 22, 2008 12:22 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: > > > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > > > > Ted, > > > > > > At the risk of receiving the wrath of the PPML Gods... > > > > > > > X-small: 61 cents/year > > > > > > X-Large fee is up to a /14. Anything over a /14 is no charge. So, > > > you cannot apply a single divisor that applies to all X-Large. The > > > > > /8 that they may also have is FREE. Most X-Large pay less > than $.01 > > > per IP. > > > > > > > "...may also have is FREE..." is a reference to legacy allocations > > and I was not talking about that, those are a separate issue. > > > > As for the penny an IP address the X-large pays, sure on > the surface > > that seems unfair. But, I will point out that precisely > because they > > are X-large, and have so many IP's already, that in a time of IPv4 > > runout, they are going to be under intense pressure to both move to > > IPv6, and also to justify why they have so much IPv4 tied up. > > > > The small low-growth organizations who have maybe a /18 > tied up, and > > who are experiencing maybe a 2% per year real growth in customer > > count, those folks aren't going to suffer in IPv4 runout > time. They > > will be paying their bills, keeping people employed, keeping their > > customers happy, basically being good citizens. They will > be able to > > sit back and weather the storm, and because they have so > little IPv4 > > tied up as compared to the large holders, nobody is going to come > > banging on their door demanding they prove justification for their > > holdings, because even if what they have has a lot of > unused numbers, > > the amount of unused numbering they have is so small it > won't help any > > of the larger well-financed consumers of IP addressing for > more than a > > few days of growth. > > > > The political and economic realities are that the X-larges > are going > > to bear the brunt of the costs of switchover to IPv6 - and > they will > > also suffer the largest customer losses, as they tell > customers that > > they can't support IPv4, those customers who don't want to switch > > (think - all of them) will be going to the smaller providers. > > > > And when the large guys have ended up funding all the R&D for the > > production deployment of IPv6, by then the small guys will have a > > literal wealth of gear and deployment strategies to pick and choose > > from, as well as be able to know all the pitfalls, AND even better, > > since they really will be the last to covert over, their customers > > will not be able to carry out the threat of "quitting service and > > finding an ISP that will sell us IPv4" since there won't BE > any ISP's > > left that will sell IPv4. > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > > allocations cost everyone on the Internet more money > per customer, > > > > because we have to carry more route entries for the same number > > > > > > It is a two-way street... > > > > > > > of customers, so I am perfectly contented with the "smaller > > > allocation > > > > tax" of more cents per IP per year > > > > > > Exactly how much of that "tax-the-poor" does your company > collect? > > > Other than providing a barrier to competition, how does > it benefit > > > your company? > > > > > > > Naturally, our pricing has to be set according to what the > other guy > > has his pricing set to - that's determined by competition. But, > > because we are smaller, we have much more flexibility in > reducing our > > internal costs than the large guy does. So we pay more for > numbering, > > but we can do things like using PC's running Quagga for BGP routers > > instead of Junipers, and the savings more than make up for the IP > > costs. (I'm not saying that we currently do this, but we > have done so > > in the past - and the reliability is no worse than the commercial > > routers) It all has a way of working out in the end. > > > > Ted > > > > > Michael Thomas > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted > Mittelstaedt > > > > Sent: Thursday, May 22, 2008 2:32 PM > > > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > > DistributionofIPv4Resources before IPv4 Run out > > > > > > > > > > > > Hey, whatever your smoking, I want some! > > > > > > > > ARIN -does- charge per IP address. I may have imbibed > a number of > > > > hallucinogenic substances over the years but the bill > we get from > > > > them every year is most definitely NOT a figment of my > > > > imagination! > > > > > > > > Or were you under the impression that ARIN was funded by > > > Tinker Bell > > > > and friends? > > > > > > > > In case you were, here is the ARIN fee schedule: > > > > > > > > http://www.arin.net/billing/fee_schedule.html > > > > > > > > Fees per IP address: > > > > > > > > X-small: 61 cents/year > > > > Small: 28 cents/year > > > > Medium: 6 cents/year > > > > Large: 3 cents/year > > > > > > > > and so forth. > > > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > > allocations cost everyone on the Internet more money > per customer, > > > > because we have to carry more route entries for the > same number of > > > > customers, so I am perfectly contented with the "smaller > > > > allocation tax" of more cents per IP per year > > > > > > > > If you go to Costco the giant bundle of toilet paper also > > > costs less > > > > per roll. That's just how things work in life. > > > > > > > > But the idea that ARIN isn't charging money for IP's is > > > > rediculous. > > > > > > > > > > > > Ted > > > > > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of > Charlie Sawyer > > > > > Sent: Thursday, May 22, 2008 11:04 AM > > > > > To: arin-ppml at arin.net > > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution > > > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > > > > > > > Ip do have value, as any business using the web to generate a > > > > > revenue stream can tell you. If Arin charged per ip, > I doubt we > > > > > would be running out of IP' addresses any time in the near > > > > > future. > > > > You would > > > > > see a lot of IP addresses being returned that were > not in use, > > > > > at the very least. > > > > > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > > > > > > > Thanks, > > > > > Charlie Sawyer > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted > > > > > Mittelstaedt > > > > > Sent: Thursday, May 22, 2008 12:25 PM > > > > > To: arin-ppml at arin.net > > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution > > > > > of IPv4Resources before IPv4 Run out > > > > > > > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > > > address distribution, which this proposal is trying > to address. > > > > > > > > > > However, I think that while the moral is a Good Thing, > > > there is no > > > > > practical way to mandate it. > > > > > > > > > > If this proposal were to be supported I would ask that the > > > > > author modify it so that at the least, there would be an > > > > > automatic expiration to this. > > > > > > > > > > The cold hard fact of the matter is that ANY isp or > other "small > > > > > or Very Small" organization that is NOT requesting IP > addressing > > > > > at this time to meet their projected future needs, is > likely to > > > > > get shafted when IPv4 runs out. > > > > > > > > > > On the day of IPv4 runout, if an ISP or organization does > > > not have a > > > > > supply of IPv4 to carry them forward for the immediate > > > future, due > > > > > to lack of planning, then I daresay they DESERVE to > go bankrupt. > > > > > > > > > > Do we really want network administrators who aren't paying > > > > > attention to the gas guage to be driving the Internet into > > > > the future? > > > > > > > > > > Ted > > > > > > > > > > > -----Original Message----- > > > > > > From: arin-ppml-bounces at arin.net > > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member > > > > > > Services > > > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > > > To: arin-ppml at arin.net > > > > > > Subject: [arin-ppml] Policy Proposal: Equitable > Distribution of > > > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > > > > > > > ARIN received the following policy proposal. In accordance > > > > > > with the ARIN Internet Resource Policy Evaluation Process, > > > the proposal > > > > > > is being posted to the ARIN Public Policy Mailing List > > > (PPML) and > > > > > > being placed on ARIN's website. > > > > > > > > > > > > The ARIN Advisory Council (AC) will review this > > > proposal at their > > > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > > > > > 1. Accept the proposal as written. If the AC > accepts the > > > > > > proposal, it will be posted as a formal policy proposal to > > > > > > PPML and it will be presented at a Public Policy Meeting. > > > > > > > > > > > > 2. Postpone their decision regarding the proposal > > > until the > > > > > > next regularly scheduled AC meeting in order to > work with the > > > > > > author. The AC will work with the author to > clarify, combine > > > > > > or divide the proposal. At their following meeting the AC > > > will accept > > > > > > or not accept the proposal. > > > > > > > > > > > > 3. Not accept the proposal. If the AC does not accept > > > > > > the proposal, the AC will explain their decision > via the PPML. > > > > > > If a proposal is not accepted, then the author may elect to > > > > > > use the petition process to advance their proposal. If the > > > author elects > > > > > > not to petition or the petition fails, then the > > > proposal will be > > > > > > closed. > > > > > > > > > > > > The AC will assign shepherds in the near future. ARIN > > > will provide > > > > > > the names of the shepherds to the community via the PPML. > > > > > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > > > 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. > > > > > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > > > can be found > > > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > > > > > Mailing list subscription information can be found at: > > > > > > http://www.arin.net/mailing_lists/ > > > > > > > > > > > > Regards, > > > > > > > > > > > > Member Services > > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > > > > ## * ## > > > > > > > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of > IPv4 Resources > > > > > > before IPv4 Run out > > > > > > > > > > > > Author: Michael K. Smith > > > > > > > > > > > > Proposal Version: 1 > > > > > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > > > > > Proposal type: new > > > > > > > > > > > > Policy term: permanent > > > > > > > > > > > > Policy statement: > > > > > > > > > > > > Upon receipt of the last allocation of IPv4 address > > > space to ARIN > > > > > > from IANA, ARIN will reserve address space within the > > > > > > allocated block for Organizations within the defined ARIN > > > > > > Organizational Size determinations (Extra Small, > Small, Large, > > > > > > Extra > > > Large) based > > > > > > upon the utilization percentages for each group > > > gathered from the > > > > > > statistics of the last two IANA allocations to ARIN. > > > In order to > > > > > > make the allocation percentages mathematically > feasible, the > > > > > > percentages will be rounded to the closest whole > number and, > > > > > > subsequently, the the closest bit boundary for > assignment the > > > > > > maximum allocation size for the Organization size > as defined > > > > > > by ARIN. > > > > > > > > > > > > Once the final IANA allocation is received, ARIN will > > > publish the > > > > > > allocation percentages that will be used for the final > > > allocation > > > > > > to the PPML and ARIN website with the necessary > documentation > > > > > > supporting the assignment of percentages. > > > > > > > > > > > > Rationale: > > > > > > > > > > > > Description: > > > > > > > > > > > > This policy is designed to allow Organizations of > the various > > > > > > defined sizes to continue to receive address > > > allocations from the > > > > > > last available space and is slanted towards ensuring that > > > > > > organizations within the Large, Small and Extra Small > > > groups (and > > > > > > more specifically, the Small and Extra Small groups) > > > are able to > > > > > > get additional IPv4 space at the end of the ARIN's > ability to > > > > > > allocate such space. Given the statistics below, > it is likely > > > > > > that Extra Large Organizations would get most or all of > > > the last > > > > > > remaining space because given the amount they have been > > > allocated > > > > > > to date. This policy would help ensure that other > > > Organizations > > > > > > had a statistically equal opportunity to receive space as > > > > > > well. > > > > > > > > > > > > > > > > > > Example: > > > > > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: > > > > > > the statistics are generated from IP allocations from 2006 > > > and 2007). > > > > > > This policy would require statistics to be limited to > > > the previous > > > > > > 2 IANA allocations to ARIN.) > > > > > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > > > > > Extra Large: 83.11% > > > > > > Large: 6.75% > > > > > > Small: 9.00% > > > > > > Extra Small: 1.14% > > > > > > > > > > > > With this example, ARIN would reserve address space in > > > the final > > > > > > IANA allocation according to those percentages, to the > > > extent that > > > > > > it is mathematically possible within the existing > > > range. In order > > > > > > to make the math work, rounding would give us: > > > > > > > > > > > > Extra Large: 83% > > > > > > Large: 7% > > > > > > Small: 9% > > > > > > Extra Small: 1% > > > > > > > > > > > > Who is affected: > > > > > > > > > > > > All ARIN Members will be affected by this policy. I > > > assume that > > > > > > smaller providers will benefit from having some space > > > available to > > > > > > them beyond where they would be with an organic > > > allocation model, > > > > > > and the Extra Large Organizations would experience > some pain > > > > > > because, using the model above, they would be excluded > > > from being > > > > > > allocated 17% of the remaining space, even if they had > > > all of the > > > > > > necessary justifications for receiving allocations > from within > > > > > > that space. > > > > > > > > > > > > Policy Enforcement: > > > > > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > > > allocations stay within the published percentages. > > > > > > > > > > > > Financial and Liability Implications: > > > > > > > > > > > > Financially, there may be additional resources required by > > > > > > ARIN Staff to allocate resources using this model. These > > > > > > resources might include application development, staff > > > > > > training > > > and tracking > > > > > > of allocations based upon the model. > > > > > > > > > > > > ARIN may have legal liability should Organizations > that were > > > > > > denied space according to the model decide to contest > > > the legality > > > > > > of the policy in court. > > > > > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > > > allocation (roughly 2011). > > > > > > > > > > > > _______________________________________________ > > > > > > PPML > > > > > > You are receiving this message because you are > > > subscribed to the > > > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe > > > > > > or manage your mailing list subscription at: > > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > > Please contact the ARIN Member Services Help Desk at > > > > > > 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 the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at > > > > > 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 the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > info at arin.net if you > > experience any issues. > > > The contents of this email message and any attachments are > confidential and are intended solely for the addressee. The > information may also be legally privileged. This transmission > is sent in trust for the sole purpose of delivery to the > intended recipient. If you have received this transmission in > error; any use, reproduction or dissemination of this > transmission is strictly prohibited. If you are not the > intended recipient, please immediately notify the sender by > reply email and delete this message and all associated attachments. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > > From mksmith at adhost.com Fri May 23 18:27:49 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 23 May 2008 15:27:49 -0700 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resourcesbefore IPv4 Run out In-Reply-To: <4E9A1234BB36494E97682CEC3958C0340611045D@slmail01.softlayer.local> References: <37FA9D1D247A4D9B82E2722EE6E5F25C@mathbox.net><78104401AB7C4B22AF163FDB02062391@tedsdesk><997BC128AE961E4A8B880CD7442D9480051186C1@NJCHLEXCMB01.cable.comcast.com> <17838240D9A5544AAA5FF95F8D520316040989A3@ad-exh01.adhost.lan> <4E9A1234BB36494E97682CEC3958C0340611045D@slmail01.softlayer.local> Message-ID: <17838240D9A5544AAA5FF95F8D52031604098AA0@ad-exh01.adhost.lan> Hello Nathan: I decided to crunch the numbers to give a little statistical meat to my argument. It's not just about protecting the little guy from the big guy. :-) Summary of Allocations/Assignments for January - May 2008 These were created using ARIN's published allocation statistics at ftp://ftp.arin.net/pub/stats/arin/delegated-arin-20080523. There was a discrepancy in the published data in that assigned blocks (all small and x-small) show up as allocated as well. As such, I counted them only once within the allocated figure below. Percentage of Allocated and Assigned Space Assigned by Size ----------------------------------------------- Large (X-Large and Large) 81% Medium (Medium) 9% Small (Small and X-Small) 10% Percentage of Allocation and Assignment Frequency by Size ----------------------------------------------- Large (X-Large and Large) 4% Medium (Medium) 17% Small (Small and X-Small) 79% Total Allocation and Assignment Size in Slash Notation (Rounded to 2 decimals) ----------------------------------------------- Large (X-Large and Large) /8.58 Medium (Medium) /11.73 Small (Small and X-Small) /11.69 I am assuming that the Frequency percentage above can correlate fairly closely to 1:1 with the number of organizations requesting space because, given that it was only 4 months, there shouldn't be multiple allocations to the same organization because they would have requested a larger block to begin with. However, I cannot confirm this so the actual ratio may be different. From this data, it seems that the policy proposal will provide some cushion for 96% of the Members at the cost of 19% space that could otherwise be assigned to Large and X-Large organizations. I then roll up these numbers will a few assumptions. 1) The Large and X-Large organizations will be market leaders in implementing IPv6, as others have discussed. 2) If they run out of IPv4 space first, they will push hard within their own organizations and to the vendors to solidify an IPv6 deployment, as others have discussed. 3) The Small/X-Small (and even Medium) Members will have a cushion of IPv4 allocations to carry them until the eye-balls are IPv6 enabled from (2) above so they will remain viable within their own markets/verticals/etc. With all of that I would like to be at the forefront of policy proposals that help the 96-percenters. Regards, Mike > -----Original Message----- > From: Nathan Day [mailto:nday at softlayer.com] > Sent: Thursday, May 22, 2008 6:53 PM > To: Michael K. Smith - Adhost; arin-ppml at arin.net > Subject: RE: [arin-ppml] > PolicyProposal:EquitableDistributionofIPv4Resourcesbefore IPv4 Run out > > Michael, > > I do agree with trying to make the most efficient use of the ipv4 resources as > we approach the end of this limited resource and I?m glad people are > discussing it. > > You don't try to hide that this proposal is for the benefit of smaller orgs at > the expense of the larger orgs. I just don't understand what qualities a > smaller org has that makes it more deserving of ipv4 resources than a larger > org. Are smaller orgs better custodians of ipv4 resources than larger orgs > based on purely their size? > > The current policies are intended to balance need and efficient use. I would > prefer to see the last blocks of ipv4 space allocated based on need and > demonstrated efficient use of previous allocations. > > Nathan Day > SoftLayer.com > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Michael K. Smith - Adhost > Sent: Thursday, May 22, 2008 7:22 PM > To: Alexander, Daniel; arin-ppml at arin.net > Subject: Re: [arin-ppml] > PolicyProposal:EquitableDistributionofIPv4Resourcesbefore IPv4 Run out > > Hello Daniel: > > I'm sure you can guess my position, but the idea that smaller organizations > would be more adversely affected at the point of depletion was part of my > rationale behind submitting a policy that was tilted at benefitting those > organizations. > > I had thought through several different models for distribution, including > flat percentages based upon org size, a model based upon only allocating in > halves the last IANA allocation (if a /14 is left, you can't allocate the /14 > to one org, only half of it, then half the remaining, etc. But, that got ugly > fast), and reserving space based upon the allocation size for the groups (x > number of /20's, x number of /22's, etc.). Using the percentages from > previous allocations seemed the most equitable and, thus, the most likely to > be palatable to orgs of every size, provided the bigger concept of helping the > smaller orgs was accepted by the community. If anyone has a better model I am > all ears. > > Regards, > > Mike > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf > > Of Alexander, Daniel > > Sent: Thursday, May 22, 2008 4:13 PM > > To: Ted Mittelstaedt; arin-ppml at arin.net > > Subject: Re: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4Resources > > before IPv4 Run out > > > > Ted, > > > > You made some points in your reply that I think echo the intent of > > Michael's proposal. Aside from how it tries to get there, I am curious > > to hear from the community on its thoughts of the rationale. > > > > Who likes the idea of a policy to handle an IANA depleted situation, > > where the smaller organizations are less effected, in order to buy them > > time, while the larger organizations are forced towards IPv6. It is the > > largest IP consumers who will drive the vendors, and develop the market > > for IPv6 enabled equipment. It is the smallest organizations who need to > > remain on IPv4 until the shift has gained the necessary momentum. > > > > When the IANA pool is depleted, regardless of whether there is a black > > market, or a paid transfer policy, it is very difficult to see a > > sufficient supply of IPv4 resources, for the extra-large ISP. This means > > that these ISP will hit the wall first, and hit it the hardest. It is > > also this group who is more able to bear the burden of working with > > equipment vendors, and software developers, to push the necessary > > momentum towards IPv6. Would a policy proposal that supports this model > > be preferred by the community? > > > > Dan Alexander > > Comcast Cable > > ARIN AC > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of Ted Mittelstaedt > > Sent: Thursday, May 22, 2008 4:42 PM > > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy > > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Thomas - > > > Mathbox > > > Sent: Thursday, May 22, 2008 12:22 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: > > > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > > > > Ted, > > > > > > At the risk of receiving the wrath of the PPML Gods... > > > > > > > X-small: 61 cents/year > > > > > > X-Large fee is up to a /14. Anything over a /14 is no charge. > > > So, you cannot apply a single divisor that applies to all X-Large. The > > > > > /8 that they may also have is FREE. Most X-Large pay less than $.01 > > > per IP. > > > > > > > "...may also have is FREE..." is a reference to legacy allocations and > > I was not talking about that, those are a separate issue. > > > > As for the penny an IP address the X-large pays, sure on the surface > > that seems unfair. But, I will point out that precisely because they > > are X-large, and have so many IP's already, that in a time of IPv4 > > runout, they are going to be under intense pressure to both move to > > IPv6, and also to justify why they have so much IPv4 tied up. > > > > The small low-growth organizations who have maybe a /18 tied up, and who > > are experiencing maybe a 2% per year real growth in customer count, > > those folks aren't going to suffer in IPv4 runout time. They will be > > paying their bills, keeping people employed, keeping their customers > > happy, basically being good citizens. > > They will be able to sit back and weather the storm, and because they > > have so little IPv4 tied up as compared to the large holders, nobody is > > going to come banging on their door demanding they prove justification > > for their holdings, because even if what they have has a lot of unused > > numbers, the amount of unused numbering they have is so small it won't > > help any of the larger well-financed consumers of IP addressing for more > > than a few days of growth. > > > > The political and economic realities are that the X-larges are going to > > bear the brunt of the costs of switchover to IPv6 - and they will also > > suffer the largest customer losses, as they tell customers that they > > can't support IPv4, those customers who don't want to switch (think - > > all of them) will be going to the smaller providers. > > > > And when the large guys have ended up funding all the R&D for the > > production deployment of IPv6, by then the small guys will have a > > literal wealth of gear and deployment strategies to pick and choose > > from, as well as be able to know all the pitfalls, AND even better, > > since they really will be the last to covert over, their customers will > > not be able to carry out the threat of "quitting service and finding an > > ISP that will sell us IPv4" > > since there won't BE any ISP's left that will sell IPv4. > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > > allocations cost everyone on the Internet more money per customer, > > > > because we have to carry more route entries for the same number > > > > > > It is a two-way street... > > > > > > > of customers, so I am perfectly contented with the "smaller > > > allocation > > > > tax" of more cents per IP per year > > > > > > Exactly how much of that "tax-the-poor" does your company collect? > > > Other than providing a barrier to competition, how does it benefit > > > your company? > > > > > > > Naturally, our pricing has to be set according to what the other guy has > > his pricing set to - that's determined by competition. > > But, because we are smaller, we have much more flexibility in reducing > > our internal costs than the large guy does. So we pay more for > > numbering, but we can do things like using PC's running Quagga for BGP > > routers instead of Junipers, and the savings more than make up for the > > IP costs. (I'm not saying that we currently do this, but we have done > > so in the past - and the reliability is no worse than the commercial > > routers) It all has a way of working out in the end. > > > > Ted > > > > > Michael Thomas > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > > Sent: Thursday, May 22, 2008 2:32 PM > > > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > > DistributionofIPv4Resources before IPv4 Run out > > > > > > > > > > > > Hey, whatever your smoking, I want some! > > > > > > > > ARIN -does- charge per IP address. I may have imbibed a number of > > > > hallucinogenic substances over the years but the bill we get from > > > > them every year is most definitely NOT a figment of my imagination! > > > > > > > > Or were you under the impression that ARIN was funded by > > > Tinker Bell > > > > and friends? > > > > > > > > In case you were, here is the ARIN fee schedule: > > > > > > > > http://www.arin.net/billing/fee_schedule.html > > > > > > > > Fees per IP address: > > > > > > > > X-small: 61 cents/year > > > > Small: 28 cents/year > > > > Medium: 6 cents/year > > > > Large: 3 cents/year > > > > > > > > and so forth. > > > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > > allocations cost everyone on the Internet more money per customer, > > > > because we have to carry more route entries for the same number of > > > > customers, so I am perfectly contented with the "smaller allocation > > > > tax" of more cents per IP per year > > > > > > > > If you go to Costco the giant bundle of toilet paper also > > > costs less > > > > per roll. That's just how things work in life. > > > > > > > > But the idea that ARIN isn't charging money for IP's is rediculous. > > > > > > > > > > > > Ted > > > > > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie Sawyer > > > > > Sent: Thursday, May 22, 2008 11:04 AM > > > > > To: arin-ppml at arin.net > > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > > > > > > > Ip do have value, as any business using the web to generate a > > > > > revenue stream can tell you. If Arin charged per ip, I doubt we > > > > > would be > > > > > running out of IP' addresses any time in the near future. > > > > You would > > > > > see a lot of IP addresses being returned that were not in use, at > > > > > the very least. > > > > > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > > > > > > > Thanks, > > > > > Charlie Sawyer > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > > > Sent: Thursday, May 22, 2008 12:25 PM > > > > > To: arin-ppml at arin.net > > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution > > > > > of IPv4Resources before IPv4 Run out > > > > > > > > > > > > > > > I support the idea of trying to equalize the last bit of IPv4 > > > > > address distribution, which this proposal is trying to address. > > > > > > > > > > However, I think that while the moral is a Good Thing, > > > there is no > > > > > practical way to mandate it. > > > > > > > > > > If this proposal were to be supported I would ask that the author > > > > > modify it so that at the least, there would be an automatic > > > > > expiration to this. > > > > > > > > > > The cold hard fact of the matter is that ANY isp or other "small > > > > > or Very Small" organization that is NOT requesting IP addressing > > > > > at this time to meet their projected future needs, is likely to > > > > > get shafted when IPv4 runs out. > > > > > > > > > > On the day of IPv4 runout, if an ISP or organization does > > > not have a > > > > > supply of IPv4 to carry them forward for the immediate > > > future, due > > > > > to lack of planning, then I daresay they DESERVE to go bankrupt. > > > > > > > > > > Do we really want network administrators who aren't paying > > > > > attention to the gas guage to be driving the Internet into > > > > the future? > > > > > > > > > > Ted > > > > > > > > > > > -----Original Message----- > > > > > > From: arin-ppml-bounces at arin.net > > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > > > To: arin-ppml at arin.net > > > > > > Subject: [arin-ppml] Policy Proposal: Equitable Distribution of > > > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > > > > > > > ARIN received the following policy proposal. In accordance with > > > > > > the ARIN Internet Resource Policy Evaluation Process, > > > the proposal > > > > > > is being posted to the ARIN Public Policy Mailing List > > > (PPML) and > > > > > > being placed on ARIN's website. > > > > > > > > > > > > The ARIN Advisory Council (AC) will review this > > > proposal at their > > > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > > > > > 1. Accept the proposal as written. If the AC accepts the > > > > > > proposal, it will be posted as a formal policy proposal to PPML > > > > > > and it will be presented at a Public Policy Meeting. > > > > > > > > > > > > 2. Postpone their decision regarding the proposal > > > until the > > > > > > next regularly scheduled AC meeting in order to work with the > > > > > > author. The AC will work with the author to clarify, combine or > > > > > > divide the proposal. At their following meeting the AC > > > will accept > > > > > > or not accept the proposal. > > > > > > > > > > > > 3. Not accept the proposal. If the AC does not accept the > > > > > > proposal, the AC will explain their decision via the PPML. If a > > > > > > proposal is not accepted, then the author may elect to use the > > > > > > petition process to advance their proposal. If the > > > author elects > > > > > > not to petition or the petition fails, then the > > > proposal will be > > > > > > closed. > > > > > > > > > > > > The AC will assign shepherds in the near future. ARIN > > > will provide > > > > > > the names of the shepherds to the community via the PPML. > > > > > > > > > > > > In the meantime, the AC invites everyone to comment on this > > > > > > 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. > > > > > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > > > can be found > > > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > > > > > Mailing list subscription information can be found at: > > > > > > http://www.arin.net/mailing_lists/ > > > > > > > > > > > > Regards, > > > > > > > > > > > > Member Services > > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > > > > ## * ## > > > > > > > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources > > > > > > before IPv4 Run out > > > > > > > > > > > > Author: Michael K. Smith > > > > > > > > > > > > Proposal Version: 1 > > > > > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > > > > > Proposal type: new > > > > > > > > > > > > Policy term: permanent > > > > > > > > > > > > Policy statement: > > > > > > > > > > > > Upon receipt of the last allocation of IPv4 address > > > space to ARIN > > > > > > from IANA, ARIN will reserve address space within the allocated > > > > > > block for Organizations within the defined ARIN Organizational > > > > > > Size determinations (Extra Small, Small, Large, Extra > > > Large) based > > > > > > upon the utilization percentages for each group > > > gathered from the > > > > > > statistics of the last two IANA allocations to ARIN. > > > In order to > > > > > > make the allocation percentages mathematically feasible, the > > > > > > percentages will be rounded to the closest whole number and, > > > > > > subsequently, the the closest bit boundary for assignment the > > > > > > maximum allocation size for the Organization size as defined by > > > > > > ARIN. > > > > > > > > > > > > Once the final IANA allocation is received, ARIN will > > > publish the > > > > > > allocation percentages that will be used for the final > > > allocation > > > > > > to the PPML and ARIN website with the necessary documentation > > > > > > supporting the assignment of percentages. > > > > > > > > > > > > Rationale: > > > > > > > > > > > > Description: > > > > > > > > > > > > This policy is designed to allow Organizations of the various > > > > > > defined sizes to continue to receive address > > > allocations from the > > > > > > last available space and is slanted towards ensuring that > > > > > > organizations within the Large, Small and Extra Small > > > groups (and > > > > > > more specifically, the Small and Extra Small groups) > > > are able to > > > > > > get additional IPv4 space at the end of the ARIN's ability to > > > > > > allocate such space. Given the statistics below, it is likely > > > > > > that Extra Large Organizations would get most or all of > > > the last > > > > > > remaining space because given the amount they have been > > > allocated > > > > > > to date. This policy would help ensure that other > > > Organizations > > > > > > had a statistically equal opportunity to receive space as well. > > > > > > > > > > > > > > > > > > Example: > > > > > > > > > > > > Please see http://www.arin.net/statistics/index.html (Note: the > > > > > > statistics are generated from IP allocations from 2006 > > > and 2007). > > > > > > This policy would require statistics to be limited to > > > the previous > > > > > > 2 IANA allocations to ARIN.) > > > > > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > > > > > Extra Large: 83.11% > > > > > > Large: 6.75% > > > > > > Small: 9.00% > > > > > > Extra Small: 1.14% > > > > > > > > > > > > With this example, ARIN would reserve address space in > > > the final > > > > > > IANA allocation according to those percentages, to the > > > extent that > > > > > > it is mathematically possible within the existing > > > range. In order > > > > > > to make the math work, rounding would give us: > > > > > > > > > > > > Extra Large: 83% > > > > > > Large: 7% > > > > > > Small: 9% > > > > > > Extra Small: 1% > > > > > > > > > > > > Who is affected: > > > > > > > > > > > > All ARIN Members will be affected by this policy. I > > > assume that > > > > > > smaller providers will benefit from having some space > > > available to > > > > > > them beyond where they would be with an organic > > > allocation model, > > > > > > and the Extra Large Organizations would experience some pain > > > > > > because, using the model above, they would be excluded > > > from being > > > > > > allocated 17% of the remaining space, even if they had > > > all of the > > > > > > necessary justifications for receiving allocations from within > > > > > > that space. > > > > > > > > > > > > Policy Enforcement: > > > > > > > > > > > > ARIN staff will have to enforce this policy and ensure that > > > > > > allocations stay within the published percentages. > > > > > > > > > > > > Financial and Liability Implications: > > > > > > > > > > > > Financially, there may be additional resources required by ARIN > > > > > > Staff to allocate resources using this model. These resources > > > > > > might include application development, staff training > > > and tracking > > > > > > of allocations based upon the model. > > > > > > > > > > > > ARIN may have legal liability should Organizations that were > > > > > > denied space according to the model decide to contest > > > the legality > > > > > > of the policy in court. > > > > > > > > > > > > Timetable for implementation: Upon receipt of finall IANA > > > > > > allocation (roughly 2011). > > > > > > > > > > > > _______________________________________________ > > > > > > PPML > > > > > > You are receiving this message because you are > > > subscribed to the > > > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe > > > > > > or manage your mailing list subscription at: > > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > > Please contact the ARIN Member Services Help Desk at > > > > > > 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 the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at > > > > 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 the ARIN Member Services Help Desk at > > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you > > experience any issues. > > > The contents of this email message and any attachments are confidential and > are intended solely for the addressee. The information may also be legally > privileged. This transmission is sent in trust for the sole purpose of > delivery to the intended recipient. If you have received this transmission in > error; any use, reproduction or dissemination of this transmission is strictly > prohibited. If you are not the intended recipient, please immediately notify > the sender by reply email and delete this message and all associated > attachments. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From tedm at ipinc.net Fri May 23 19:55:11 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 23 May 2008 16:55:11 -0700 Subject: [arin-ppml] PolicyProposal:EquitableDistributionofIPv4ResourcesbeforeIPv4 Run out In-Reply-To: <17838240D9A5544AAA5FF95F8D52031604098AA0@ad-exh01.adhost.lan> Message-ID: Thanks for running the numbers to inject a little math into the discussion. I really, really want to see a sunset clause in this proposal. My gut feeling is that if there is not a sunset clause, that some bozo somewhere (unlikely that it would be an X-large) would take the opportunity to file a lawsuit, primariarly with the goal of getting IP addresses ruled as intellectual property in a court somewhere. A sunset clause wouldn't protect this from happening, but it would definitely give any lawyer involved a far narrower window to file such a suit, and make it much more difficult to prove damages had occurred. As a result I think it would cause any lawyer contracted to file such a suite to demand cash up front, which would likely kibosh attempts to do this. It also makes good sense to make ineffective any regulations that are no longer applicable. Once the last IPv4 is assigned, this regulation would definitely not be applicable. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. > Smith - Adhost > Sent: Friday, May 23, 2008 3:28 PM > To: Nathan Day; arin-ppml at arin.net > Subject: Re: > [arin-ppml]PolicyProposal:EquitableDistributionofIPv4Resources > beforeIPv4 Run out > > > Hello Nathan: > > I decided to crunch the numbers to give a little statistical > meat to my argument. It's not just about protecting the > little guy from the big guy. :-) > > Summary of Allocations/Assignments for January - May 2008 > > These were created using ARIN's published allocation > statistics at > ftp://ftp.arin.net/pub/stats/arin/delegated-arin-20080523. > > There was a discrepancy in the published data in that > assigned blocks (all small and x-small) show up as allocated > as well. As such, I counted them only once within the > allocated figure below. > > Percentage of Allocated and Assigned Space Assigned by Size > ----------------------------------------------- > Large (X-Large and Large) 81% > Medium (Medium) 9% > Small (Small and X-Small) 10% > > Percentage of Allocation and Assignment Frequency by Size > ----------------------------------------------- > Large (X-Large and Large) 4% > Medium (Medium) 17% > Small (Small and X-Small) 79% > > Total Allocation and Assignment Size in Slash Notation > (Rounded to 2 decimals) > ----------------------------------------------- > Large (X-Large and Large) /8.58 > Medium (Medium) /11.73 > Small (Small and X-Small) /11.69 > > I am assuming that the Frequency percentage above can > correlate fairly closely to 1:1 with the number of > organizations requesting space because, given that it was > only 4 months, there shouldn't be multiple allocations to the > same organization because they would have requested a larger > block to begin with. However, I cannot confirm this so the > actual ratio may be different. > > From this data, it seems that the policy proposal will > provide some cushion for 96% of the Members at the cost of > 19% space that could otherwise be assigned to Large and > X-Large organizations. > > I then roll up these numbers will a few assumptions. > > 1) The Large and X-Large organizations will be market leaders > in implementing IPv6, as others have discussed. > 2) If they run out of IPv4 space first, they will push hard > within their own organizations and to the vendors to solidify > an IPv6 deployment, as others have discussed. > 3) The Small/X-Small (and even Medium) Members will have a > cushion of IPv4 allocations to carry them until the eye-balls > are IPv6 enabled from (2) above so they will remain viable > within their own markets/verticals/etc. > > With all of that I would like to be at the forefront of > policy proposals that help the 96-percenters. > > Regards, > > Mike > > > > -----Original Message----- > > From: Nathan Day [mailto:nday at softlayer.com] > > Sent: Thursday, May 22, 2008 6:53 PM > > To: Michael K. Smith - Adhost; arin-ppml at arin.net > > Subject: RE: [arin-ppml] > > PolicyProposal:EquitableDistributionofIPv4Resourcesbefore > IPv4 Run out > > > > Michael, > > > > I do agree with trying to make the most efficient use of the ipv4 > > resources as we approach the end of this limited resource > and I'm glad > > people are discussing it. > > > > You don't try to hide that this proposal is for the benefit > of smaller > > orgs at the expense of the larger orgs. I just don't > understand what > > qualities a smaller org has that makes it more deserving of ipv4 > > resources than a larger org. Are smaller orgs better custodians of > > ipv4 resources than larger orgs based on purely their size? > > > > The current policies are intended to balance need and > efficient use. > > I would prefer to see the last blocks of ipv4 space > allocated based on > > need and demonstrated efficient use of previous allocations. > > > > Nathan Day > > SoftLayer.com > > > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Michael K. Smith - Adhost > > Sent: Thursday, May 22, 2008 7:22 PM > > To: Alexander, Daniel; arin-ppml at arin.net > > Subject: Re: [arin-ppml] > > PolicyProposal:EquitableDistributionofIPv4Resourcesbefore > IPv4 Run out > > > > Hello Daniel: > > > > I'm sure you can guess my position, but the idea that smaller > > organizations would be more adversely affected at the point of > > depletion was part of my rationale behind submitting a > policy that was > > tilted at benefitting those organizations. > > > > I had thought through several different models for distribution, > > including flat percentages based upon org size, a model based upon > > only allocating in halves the last IANA allocation (if a > /14 is left, > > you can't allocate the /14 to one org, only half of it, > then half the > > remaining, etc. But, that got ugly fast), and reserving space based > > upon the allocation size for the groups (x number of /20's, > x number > > of /22's, etc.). Using the percentages from previous allocations > > seemed the most equitable and, thus, the most likely to be > palatable > > to orgs of every size, provided the bigger concept of helping the > > smaller orgs was accepted by the community. If anyone has a better > > model I am all ears. > > > > Regards, > > > > Mike > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > > On > > Behalf > > > Of Alexander, Daniel > > > Sent: Thursday, May 22, 2008 4:13 PM > > > To: Ted Mittelstaedt; arin-ppml at arin.net > > > Subject: Re: [arin-ppml] > > > PolicyProposal:EquitableDistributionofIPv4Resources > > > before IPv4 Run out > > > > > > Ted, > > > > > > You made some points in your reply that I think echo the > intent of > > > Michael's proposal. Aside from how it tries to get there, I am > > > curious to hear from the community on its thoughts of the > rationale. > > > > > > Who likes the idea of a policy to handle an IANA depleted > situation, > > > where the smaller organizations are less effected, in > order to buy > > > them time, while the larger organizations are forced > towards IPv6. > > > It is the largest IP consumers who will drive the vendors, and > > > develop the market for IPv6 enabled equipment. It is the smallest > > > organizations who need to remain on IPv4 until the shift > has gained > > > the necessary momentum. > > > > > > When the IANA pool is depleted, regardless of whether there is a > > > black market, or a paid transfer policy, it is very > difficult to see > > > a sufficient supply of IPv4 resources, for the > extra-large ISP. This > > > means that these ISP will hit the wall first, and hit it the > > > hardest. It is also this group who is more able to bear > the burden > > > of working with equipment vendors, and software > developers, to push > > > the necessary momentum towards IPv6. Would a policy proposal that > > > supports this model be preferred by the community? > > > > > > Dan Alexander > > > Comcast Cable > > > ARIN AC > > > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > > On Behalf Of Ted Mittelstaedt > > > Sent: Thursday, May 22, 2008 4:42 PM > > > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy > > > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of > Michael Thomas - > > > > Mathbox > > > > Sent: Thursday, May 22, 2008 12:22 PM > > > > To: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: > > > > EquitableDistributionofIPv4Resources before IPv4 Run out > > > > > > > > > > > > Ted, > > > > > > > > At the risk of receiving the wrath of the PPML Gods... > > > > > > > > > X-small: 61 cents/year > > > > > > > > X-Large fee is up to a /14. Anything over a /14 is no > charge. So, > > > > you cannot apply a single divisor that applies to all > X-Large. The > > > > > > > /8 that they may also have is FREE. Most X-Large pay less than > > > > $.01 per IP. > > > > > > > > > > "...may also have is FREE..." is a reference to legacy > allocations > > > and I was not talking about that, those are a separate issue. > > > > > > As for the penny an IP address the X-large pays, sure on > the surface > > > that seems unfair. But, I will point out that precisely because > > > they are X-large, and have so many IP's already, that in > a time of > > > IPv4 runout, they are going to be under intense pressure to both > > > move to IPv6, and also to justify why they have so much IPv4 tied > > > up. > > > > > > The small low-growth organizations who have maybe a /18 > tied up, and > > > who are experiencing maybe a 2% per year real growth in customer > > > count, those folks aren't going to suffer in IPv4 runout > time. They > > > will be paying their bills, keeping people employed, > keeping their > > > customers happy, basically being good citizens. They will > be able to > > > sit back and weather the storm, and because they have so > little IPv4 > > > tied up as compared to the large holders, nobody is going to come > > > banging on their door demanding they prove justification > for their > > > holdings, because even if what they have has a lot of unused > > > numbers, the amount of unused numbering they have is so small it > > > won't help any of the larger well-financed consumers of IP > > > addressing for more than a few days of growth. > > > > > > The political and economic realities are that the > X-larges are going > > > to bear the brunt of the costs of switchover to IPv6 - > and they will > > > also suffer the largest customer losses, as they tell > customers that > > > they can't support IPv4, those customers who don't want to switch > > > (think - all of them) will be going to the smaller providers. > > > > > > And when the large guys have ended up funding all the R&D for the > > > production deployment of IPv6, by then the small guys will have a > > > literal wealth of gear and deployment strategies to pick > and choose > > > from, as well as be able to know all the pitfalls, AND > even better, > > > since they really will be the last to covert over, their > customers > > > will not be able to carry out the threat of "quitting service and > > > finding an ISP that will sell us IPv4" since there won't BE any > > > ISP's left that will sell IPv4. > > > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > > > allocations cost everyone on the Internet more money per > > > > > customer, because we have to carry more route entries for the > > > > > same number > > > > > > > > It is a two-way street... > > > > > > > > > of customers, so I am perfectly contented with the "smaller > > > > allocation > > > > > tax" of more cents per IP per year > > > > > > > > Exactly how much of that "tax-the-poor" does your > company collect? > > > > Other than providing a barrier to competition, how does > it benefit > > > > your company? > > > > > > > > > > Naturally, our pricing has to be set according to what > the other guy > > > has his pricing set to - that's determined by competition. But, > > > because we are smaller, we have much more flexibility in reducing > > > our internal costs than the large guy does. So we pay more for > > > numbering, but we can do things like using PC's running > Quagga for > > > BGP routers instead of Junipers, and the savings more > than make up > > > for the IP costs. (I'm not saying that we currently do > this, but we > > > have done so in the past - and the reliability is no > worse than the > > > commercial > > > routers) It all has a way of working out in the end. > > > > > > Ted > > > > > > > Michael Thomas > > > > > > > > > -----Original Message----- > > > > > From: arin-ppml-bounces at arin.net > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted > > > > > Mittelstaedt > > > > > Sent: Thursday, May 22, 2008 2:32 PM > > > > > To: 'Charlie Sawyer'; arin-ppml at arin.net > > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > > > > > DistributionofIPv4Resources before IPv4 Run out > > > > > > > > > > > > > > > Hey, whatever your smoking, I want some! > > > > > > > > > > ARIN -does- charge per IP address. I may have > imbibed a number > > > > > of hallucinogenic substances over the years but the > bill we get > > > > > from them every year is most definitely NOT a figment of my > > > > > imagination! > > > > > > > > > > Or were you under the impression that ARIN was funded by > > > > Tinker Bell > > > > > and friends? > > > > > > > > > > In case you were, here is the ARIN fee schedule: > > > > > > > > > > http://www.arin.net/billing/fee_schedule.html > > > > > > > > > > Fees per IP address: > > > > > > > > > > X-small: 61 cents/year > > > > > Small: 28 cents/year > > > > > Medium: 6 cents/year > > > > > Large: 3 cents/year > > > > > > > > > > and so forth. > > > > > > > > > > The fact of the matter is that on a per-IP basis, the smaller > > > > > allocations cost everyone on the Internet more money per > > > > > customer, because we have to carry more route entries for the > > > > > same number of customers, so I am perfectly contented > with the > > > > > "smaller allocation tax" of more cents per IP per year > > > > > > > > > > If you go to Costco the giant bundle of toilet paper also > > > > costs less > > > > > per roll. That's just how things work in life. > > > > > > > > > > But the idea that ARIN isn't charging money for IP's is > > > > > rediculous. > > > > > > > > > > > > > > > Ted > > > > > > > > > > > -----Original Message----- > > > > > > From: arin-ppml-bounces at arin.net > > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charlie > > > > > > Sawyer > > > > > > Sent: Thursday, May 22, 2008 11:04 AM > > > > > > To: arin-ppml at arin.net > > > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution > > > > > > ofIPv4Resources before IPv4 Run out > > > > > > > > > > > > > > > > > > Ip do have value, as any business using the web to > generate a > > > > > > revenue stream can tell you. If Arin charged per > ip, I doubt > > > > > > we would be running out of IP' addresses any time > in the near > > > > > > future. > > > > > You would > > > > > > see a lot of IP addresses being returned that were > not in use, > > > > > > at the very least. > > > > > > > > > > > > Supply and demand with free market can solve many issues. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Charlie Sawyer > > > > > > -----Original Message----- > > > > > > From: arin-ppml-bounces at arin.net > > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted > > > > > > Mittelstaedt > > > > > > Sent: Thursday, May 22, 2008 12:25 PM > > > > > > To: arin-ppml at arin.net > > > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution > > > > > > of IPv4Resources before IPv4 Run out > > > > > > > > > > > > > > > > > > I support the idea of trying to equalize the last > bit of IPv4 > > > > > > address distribution, which this proposal is trying to > > > > > > address. > > > > > > > > > > > > However, I think that while the moral is a Good Thing, > > > > there is no > > > > > > practical way to mandate it. > > > > > > > > > > > > If this proposal were to be supported I would ask that the > > > > > > author modify it so that at the least, there would be an > > > > > > automatic expiration to this. > > > > > > > > > > > > The cold hard fact of the matter is that ANY isp or other > > > > > > "small or Very Small" organization that is NOT > requesting IP > > > > > > addressing at this time to meet their projected > future needs, > > > > > > is likely to get shafted when IPv4 runs out. > > > > > > > > > > > > On the day of IPv4 runout, if an ISP or organization does > > > > not have a > > > > > > supply of IPv4 to carry them forward for the immediate > > > > future, due > > > > > > to lack of planning, then I daresay they DESERVE to go > > > > > > bankrupt. > > > > > > > > > > > > Do we really want network administrators who aren't paying > > > > > > attention to the gas guage to be driving the Internet into > > > > > the future? > > > > > > > > > > > > Ted > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: arin-ppml-bounces at arin.net > > > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member > > > > > > > Services > > > > > > > Sent: Wednesday, May 21, 2008 7:37 AM > > > > > > > To: arin-ppml at arin.net > > > > > > > Subject: [arin-ppml] Policy Proposal: Equitable > Distribution of > > > > > > > IPv4 Resources before IPv4 Run out > > > > > > > > > > > > > > > > > > > > > ARIN received the following policy proposal. In > accordance > > > > > > > with the ARIN Internet Resource Policy Evaluation Process, > > > > the proposal > > > > > > > is being posted to the ARIN Public Policy Mailing List > > > > (PPML) and > > > > > > > being placed on ARIN's website. > > > > > > > > > > > > > > The ARIN Advisory Council (AC) will review this > > > > proposal at their > > > > > > > next regularly scheduled meeting. The AC may decide to: > > > > > > > > > > > > > > 1. Accept the proposal as written. If the > AC accepts > > > > > > > the proposal, it will be posted as a formal > policy proposal > > > > > > > to PPML and it will be presented at a Public > Policy Meeting. > > > > > > > > > > > > > > 2. Postpone their decision regarding the proposal > > > > until the > > > > > > > next regularly scheduled AC meeting in order to work with > > > > > > > the author. The AC will work with the author to clarify, > > > > > > > combine or divide the proposal. At their > following meeting > > > > > > > the AC > > > > will accept > > > > > > > or not accept the proposal. > > > > > > > > > > > > > > 3. Not accept the proposal. If the AC does > not accept > > > > > > > the proposal, the AC will explain their decision via the > > > > > > > PPML. If a proposal is not accepted, then the author may > > > > > > > elect to use the petition process to advance > their proposal. > > > > > > > If the > > > > author elects > > > > > > > not to petition or the petition fails, then the > > > > proposal will be > > > > > > > closed. > > > > > > > > > > > > > > The AC will assign shepherds in the near future. ARIN > > > > will provide > > > > > > > the names of the shepherds to the community via the PPML. > > > > > > > > > > > > > > In the meantime, the AC invites everyone to > comment on this > > > > > > > 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. > > > > > > > > > > > > > > The ARIN Internet Resource Policy Evaluation Process > > > > can be found > > > > > > > at: http://www.arin.net/policy/irpep.html > > > > > > > > > > > > > > Mailing list subscription information can be found at: > > > > > > > http://www.arin.net/mailing_lists/ > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Member Services > > > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > > > > > > > ## * ## > > > > > > > > > > > > > > > > > > > > > Policy Proposal Name: Equitable Distribution of IPv4 > > > > > > > Resources before IPv4 Run out > > > > > > > > > > > > > > Author: Michael K. Smith > > > > > > > > > > > > > > Proposal Version: 1 > > > > > > > > > > > > > > Submission Date: 05/20/2008 > > > > > > > > > > > > > > Proposal type: new > > > > > > > > > > > > > > Policy term: permanent > > > > > > > > > > > > > > Policy statement: > > > > > > > > > > > > > > Upon receipt of the last allocation of IPv4 address > > > > space to ARIN > > > > > > > from IANA, ARIN will reserve address space within the > > > > > > > allocated block for Organizations within the defined ARIN > > > > > > > Organizational Size determinations (Extra Small, Small, > > > > > > > Large, Extra > > > > Large) based > > > > > > > upon the utilization percentages for each group > > > > gathered from the > > > > > > > statistics of the last two IANA allocations to ARIN. > > > > In order to > > > > > > > make the allocation percentages mathematically > feasible, the > > > > > > > percentages will be rounded to the closest whole > number and, > > > > > > > subsequently, the the closest bit boundary for assignment > > > > > > > the maximum allocation size for the Organization size as > > > > > > > defined by ARIN. > > > > > > > > > > > > > > Once the final IANA allocation is received, ARIN will > > > > publish the > > > > > > > allocation percentages that will be used for the final > > > > allocation > > > > > > > to the PPML and ARIN website with the necessary > > > > > > > documentation supporting the assignment of percentages. > > > > > > > > > > > > > > Rationale: > > > > > > > > > > > > > > Description: > > > > > > > > > > > > > > This policy is designed to allow Organizations of the > > > > > > > various defined sizes to continue to receive address > > > > allocations from the > > > > > > > last available space and is slanted towards ensuring that > > > > > > > organizations within the Large, Small and Extra Small > > > > groups (and > > > > > > > more specifically, the Small and Extra Small groups) > > > > are able to > > > > > > > get additional IPv4 space at the end of the > ARIN's ability > > > > > > > to allocate such space. Given the statistics > below, it is > > > > > > > likely that Extra Large Organizations would get > most or all > > > > > > > of > > > > the last > > > > > > > remaining space because given the amount they have been > > > > allocated > > > > > > > to date. This policy would help ensure that other > > > > Organizations > > > > > > > had a statistically equal opportunity to receive space as > > > > > > > well. > > > > > > > > > > > > > > > > > > > > > Example: > > > > > > > > > > > > > > Please see > http://www.arin.net/statistics/index.html (Note: > > > > > > > the statistics are generated from IP allocations from 2006 > > > > and 2007). > > > > > > > This policy would require statistics to be limited to > > > > the previous > > > > > > > 2 IANA allocations to ARIN.) > > > > > > > > > > > > > > The present distribution as of May 20th 2008 is: > > > > > > > > > > > > > > Extra Large: 83.11% > > > > > > > Large: 6.75% > > > > > > > Small: 9.00% > > > > > > > Extra Small: 1.14% > > > > > > > > > > > > > > With this example, ARIN would reserve address space in > > > > the final > > > > > > > IANA allocation according to those percentages, to the > > > > extent that > > > > > > > it is mathematically possible within the existing > > > > range. In order > > > > > > > to make the math work, rounding would give us: > > > > > > > > > > > > > > Extra Large: 83% > > > > > > > Large: 7% > > > > > > > Small: 9% > > > > > > > Extra Small: 1% > > > > > > > > > > > > > > Who is affected: > > > > > > > > > > > > > > All ARIN Members will be affected by this policy. I > > > > assume that > > > > > > > smaller providers will benefit from having some space > > > > available to > > > > > > > them beyond where they would be with an organic > > > > allocation model, > > > > > > > and the Extra Large Organizations would > experience some pain > > > > > > > because, using the model above, they would be excluded > > > > from being > > > > > > > allocated 17% of the remaining space, even if they had > > > > all of the > > > > > > > necessary justifications for receiving allocations from > > > > > > > within that space. > > > > > > > > > > > > > > Policy Enforcement: > > > > > > > > > > > > > > ARIN staff will have to enforce this policy and > ensure that > > > > > > > allocations stay within the published percentages. > > > > > > > > > > > > > > Financial and Liability Implications: > > > > > > > > > > > > > > Financially, there may be additional resources > required by > > > > > > > ARIN Staff to allocate resources using this model. These > > > > > > > resources might include application development, staff > > > > > > > training > > > > and tracking > > > > > > > of allocations based upon the model. > > > > > > > > > > > > > > ARIN may have legal liability should > Organizations that were > > > > > > > denied space according to the model decide to contest > > > > the legality > > > > > > > of the policy in court. > > > > > > > > > > > > > > Timetable for implementation: Upon receipt of > finall IANA > > > > > > > allocation (roughly 2011). > > > > > > > > > > > > > > _______________________________________________ > > > > > > > PPML > > > > > > > You are receiving this message because you are > > > > subscribed to the > > > > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe > > > > > > > or manage your mailing list subscription at: > > > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > > > Please contact the ARIN Member Services Help Desk at > > > > > > > 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 the ARIN Member Services Help Desk at > > > > > 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 the ARIN Member Services Help Desk at > > > > > > 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 the ARIN Member Services Help Desk at > > > > > 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 the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > 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 the ARIN Member Services Help Desk at > info at arin.net if you > > > experience any issues. > > > > > > The contents of this email message and any attachments are > confidential and > > are intended solely for the addressee. The information may > also be legally > > privileged. This transmission is sent in trust for the sole > purpose of > > delivery to the intended recipient. If you have received > this transmission in > > error; any use, reproduction or dissemination of this > transmission is strictly > > prohibited. If you are not the intended recipient, please > immediately notify > > the sender by reply email and delete this message and all associated > > attachments. >