From narten at us.ibm.com Fri Jul 5 00:53:03 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 05 Jul 2013 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201307050453.r654r3HA001800@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Jul 5 00:53:03 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 7089 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 7089 | Total From info at arin.net Mon Jul 8 12:11:57 2013 From: info at arin.net (ARIN) Date: Mon, 08 Jul 2013 12:11:57 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - June 2013 In-Reply-To: <51C9B970.1020104@arin.net> References: <51C9B970.1020104@arin.net> Message-ID: <51DAE4CD.1030501@arin.net> > The AC abandoned ARIN-2013-1 and ARIN-2013-2. Anyone dissatisfied with > these decisions may initiate a petition. The deadline to begin a > petition will be five business days after the AC's draft meeting minutes > are published. The minutes of the AC's 20 June 2013 meeting have been published and are available at: https://www.arin.net/about_us/ac/index.html The deadline to begin a petition is 12 July 2013. In addition to the minutes, the AC also provided the following statements: "Based on the feedback received at the ARIN 31 Public Policy Meeting, and at the Public Policy Consultation at NANOG 58, the ARIN AC voted to abandon ARIN-2013-1 "Section 8.4 Inter-RIR Transfers of ASNs". The feedback from the community indicated that many people felt the policy was unnecessary as it would have no effect until/unless another RIR expresses interest in allowing Inter-RIR ASN transfers as well. Based on the feedback received at the ARIN 31 Public Policy Meeting, and at the Public Policy Consultation at NANOG 58, the ARIN AC voted to abandon ARIN-2013-2 "3GPP Network IP Resource Policy". The feedback from the community indicated a consensus that this issue was not worth addressing in policy at this time." Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 6/25/13 11:38 AM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN > Advisory Council (AC) held a meeting on 20 June 2013 and made decisions > about draft policies and proposals. > > The AC accepted the following Proposal as a Draft Policy. It will be > posted separately to the Public Policy Mailing List. > > ARIN-prop-189 Allocation of IPv4 and IPv6 Address Space to Out-of-region > Requestors > > The AC recommended that the following be sent to the Board as an > editorial change: > > ARIN-prop-186 Section 8.2 Reorganizations > > The AC is continuing to work on the following: > > Draft Policy ARIN-2013-4: RIR Principles > Draft Policy ARIN-2013-5: LIR/ISP and End-user Definitions > > The AC abandoned the following: > > Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers of > ASNs > Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy > > The AC abandoned ARIN-2013-1 and ARIN-2013-2. Anyone dissatisfied with > these decisions may initiate a petition. The deadline to begin a > petition will be five business days after the AC's draft meeting minutes > are published. For more information on starting and participating in > petitions, see PDP Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jul 8 17:34:46 2013 From: info at arin.net (ARIN) Date: Mon, 08 Jul 2013 17:34:46 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51966083.2010003@arin.net> References: <51966083.2010003@arin.net> Message-ID: <51DB3076.5080304@arin.net> Draft Policy ARIN-2013-4 RIR Principles Revised text for ARIN-2013-4 is below and can be found at: https://www.arin.net/policy/proposals/2013_4.html The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2013-4 RIR Principles Policy Statement (v2 8 July 2013): Section 0: Principles and Goals of the Internet Registry System 0.1. Registration The principle of registration guarantees the uniqueness of Internet number resources. Provision of this public registry documenting Internet number resource allocation, reallocation, assignment, and reassignment is necessary: a) to ensure uniqueness and to to provide operational staff with information on who is using each number resource, b) to provide a contact in case of operational/security problems, c) to provide the transparency required to ensure that Internet number resources are efficiently utilized, and d) to assist in IP allocation studies. 0.1. Conservation The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources. Due to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks. 0.2. Routability The principle of routability guarantees that Internet number resources are managed in such a manner that they may be routed on the Internet in a scalable manner. Routing scalability is necessary to ensure proper operation of Internet routing, although it must be stressed that routability is in no way guaranteed with the allocation or assignment of Internet number resources. 0.4. Stewardship The principle of stewardship guarantees the application of these principles when managing Internet number resources. It should be noted that the above goals may sometimes be in conflict with each other and with the interests of individual end-users or network operators. Care must be taken to ensure balance with these conflicting goals given the resource availability, relative size of the resource, and number resource specific technical dynamics, for each type of number resource. For example, Conservation often requires greater consideration in IPv4 address distribution due to the limited size of the address space, Routability has a higher weight for the massive IPv6 address space, and AS numbers place the highest value on Registration because they come from a moderately sized pool and are not subject to aggregation. On 5/17/13 12:53 PM, ARIN wrote: > Draft Policy ARIN-2013-4 > RIR Principles > > On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187 > RIR Principles" as a Draft Policy. > > Draft Policy ARIN-2013-4 is below and can be found at: > https://www.arin.net/policy/proposals/2013_4.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2013-4 on the Public Policy Mailing List. 2013-4 will also be on > the agenda at the upcoming ARIN Public Policy Consultation at NANOG 58 > in New Orleans. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2013-4 > RIR Principles > > Date: 17 May 2013 > > Problem Statement: > > The original text in RFC 2050 both "describes the registry system for > the distribution of globally unique Internet address space and registry > operations" and provides "rules and guidelines [principles] governing > the distribution of this address space." > > The currently proposed update (RFC2050bis) "provides information about > the current Internet Numbers Registry System used in the distribution of > globally unique Internet Protocol (IP) address space and autonomous > system (AS) numbers" and "provides information about the processes for > further evolution of the Internet Numbers Registry System." > > This means that the guiding principles of stewardship are not currently > being carried forward into the new document. The goals of Conservation > (efficient utilization based on need), Routability (hierarchical > aggregation), and Registration (uniqueness) are as important, if not > more so, now that the transition to IPv6 is upon us. This can be > rectified by documenting these principles in RIR policy. > > Policy Statement: > > Section 0: Principles and Goals of the Internet Registry System > > 0.1. Efficient utilization based on need (Conservation) > > Policies for managing Internet number resources must support fair > distribution of globally unique Internet address space according to the > operational needs of the end-users and Internet Service Providers > operating networks using this address space. The registry should prevent > stockpiling in order to maximize the conservation and efficient > utilization of the Internet address space. > > 0.1.1. Documented Justified Need (Needs Based) > > Assignment of Internet number resources is based on documented > operational need. Utilization rate of address space will be a key factor > in number resource assignment. To this end, registrants should have > documented justified need available for each assignment. Organizations > will be assigned resources based on immediate utilization plus expected > utilization. > > In order to promote increased usage of Internet number resources, > resource holders will be required to provide an accounting of resources > currently held demonstrating efficient utilization. Internet number > resources are valid as long as the criteria continues to be met. The > transfer of Internet number resources from one party to another must be > approved by the regional registries. The party trying to obtain the > resources must meet the same criteria as if they were requesting > resources directly from the IR. > > All Internet number resource requests are subject to audit and > verification by any means deemed appropriate by the regional registry. > > 0.2. Hierarchical aggregation (Routability) > > Policies for managing Internet number resources must support > distribution of globally unique Internet addresses in a hierarchical > manner, permitting the routing scalability of the addresses. This > scalability is necessary to ensure proper operation of Internet routing, > although it must be stressed that routability is in no way guaranteed > with the allocation or assignment of IPv4 addresses. > > 0.3. Uniqueness (Registration) > > Provision of a public registry documenting Internet number resource > allocation, reallocation, assignment, and reassignment is necessary to: > > a) ensure uniqueness and to to provide operational staff with > information on who is using the number resource b) to provide a contact > in case of operational/security problems (e.g. Law Enforcement) c) to > ensure that a provider has exhausted a majority of its current CIDR > allocation, thereby justifying an additional allocation d) to assist in > IP allocation studies. > > It is imperative that reassignment information be submitted in a prompt > and efficient manner to facilitate database maintenance and ensure > database integrity. > > 0.4. Stewardship > > It should be noted that efficient utilization and hierarchical > aggregation are often conflicting goals. All the above goals may > sometimes be in conflict with the interests of individual end-users or > Internet Service Providers. Care must be taken to ensure balance with > these conflicting goals given the resource availability, relative size > of the resource, and number resource specific technical dynamics, for > each type of number resource. For example, efficient utilization becomes > a more prominent issue than aggregation as the IPv4 free pool depletes > and IPv4 resource availability in any transfer market decreases. > Conversely, because the IPv6 number space is orders of magnitude larger > than the IPv4 number space, the scale tips away from efficient > utilization towards hierarchical aggregation for IPv6 number resources. > > Comments: > > a. Timetable for implementation: immediately > > b. I believe that it would be beneficial for IANA to adopt these > principles as well, and encourage the community to consider a global > policy proposal. From farmer at umn.edu Mon Jul 8 18:02:47 2013 From: farmer at umn.edu (David Farmer) Date: Mon, 08 Jul 2013 17:02:47 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DB3076.5080304@arin.net> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: <51DB3707.102@umn.edu> My first reaction is I mostly like the update, but I immediately see a few nits; On 7/8/13 16:34 , ARIN wrote: ... > Draft Policy ARIN-2013-4 > RIR Principles > > Policy Statement (v2 8 July 2013): > > Section 0: Principles and Goals of the Internet Registry System > > 0.1. Registration Both Registration & Conservation are identified as sub-sections 0.1. > The principle of registration guarantees the uniqueness of Internet > number resources. > > Provision of this public registry documenting Internet number resource > allocation, reallocation, assignment, and reassignment is necessary: > > a) to ensure uniqueness and to to provide operational staff with > information on who is using each number resource, There is an implied and between each of these, so make a) a compound clause seems unnecessary and somewhat confusing. I'd suggest split a) into two, shifting the rest down, proving; a) to ensure uniqueness, b) to provide operational staff with information on who is using each number resource, This provides more punch to a) and just seems cleaner. > b) to provide a contact in case of operational/security problems, > c) to provide the transparency required to ensure that Internet number > resources are efficiently utilized, and > d) to assist in IP allocation studies. > > 0.1. Conservation Again, both Registration & Conservation are identified as sub-sections 0.1. I'd suggest making Conservation sub-sections 0.2, and shifting the rest down. ... -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer at umn.edu Mon Jul 8 18:10:09 2013 From: farmer at umn.edu (David Farmer) Date: Mon, 08 Jul 2013 17:10:09 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DB3707.102@umn.edu> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB3707.102@umn.edu> Message-ID: <51DB38C1.70500@umn.edu> On 7/8/13 17:02 , David Farmer wrote: > My first reaction is I mostly like the update, but I immediately see a > few nits; I launched my first reaction a little too soon; more below. > On 7/8/13 16:34 , ARIN wrote: > ... >> Draft Policy ARIN-2013-4 >> RIR Principles >> >> Policy Statement (v2 8 July 2013): >> >> Section 0: Principles and Goals of the Internet Registry System >> >> 0.1. Registration > > Both Registration & Conservation are identified as sub-sections 0.1. > >> The principle of registration guarantees the uniqueness of Internet >> number resources. >> >> Provision of this public registry documenting Internet number resource >> allocation, reallocation, assignment, and reassignment is necessary: >> >> a) to ensure uniqueness and to to provide operational staff with >> information on who is using each number resource, > > There is an implied and between each of these, so make a) a compound > clause seems unnecessary and somewhat confusing. I'd suggest split a) > into two, shifting the rest down, proving; > > a) to ensure uniqueness, > b) to provide operational staff with information on who is using each > number resource, > > This provides more punch to a) and just seems cleaner. > >> b) to provide a contact in case of operational/security problems, >> c) to provide the transparency required to ensure that Internet number >> resources are efficiently utilized, and >> d) to assist in IP allocation studies. It's even worse that I initially saw, the second clause of a) duplicates b) so it should be; a) to ensure uniqueness, b) to provide a contact in case of operational/security problems, c) to provide the transparency required to ensure that Internet number resources are efficiently utilized, and d) to assist in IP allocation studies. >> 0.1. Conservation > > Again, both Registration & Conservation are identified as sub-sections > 0.1. I'd suggest making Conservation sub-sections 0.2, and shifting the > rest down. > > ... > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bill at herrin.us Mon Jul 8 18:40:40 2013 From: bill at herrin.us (William Herrin) Date: Mon, 8 Jul 2013 18:40:40 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DB3076.5080304@arin.net> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: I support this as written but have a couple of comments and suggestions. On Mon, Jul 8, 2013 at 5:34 PM, ARIN wrote: > Draft Policy ARIN-2013-4 > RIR Principles Did you mean ARIN registry principles or is this intended to be offered as a global policy? > 0.1. Conservation > > The principle of conservation guarantees sustainability of the > Internet through efficient utilization of unique number resources. I would flip those around. I think the principle is: sustainable use of number resources. Conservation is one tool which facilitates sustainable use in some circumstances. Technical/documented/justified need is another such tool. Retaining conservation as the core principle, we'll end up dancing around the stewardship issue a lot more often that we really ought to. Gee, we don't have to conserve AS numbers because of stewardship! Huh? No. We don't have to conserve AS numbers because at $550 a pop we easily achieve sustainable use without any other attempt at conserving them. At $550 each, we wouldn't need to conserve IPv4 addresses either! > 0.2. Routability > > The principle of routability guarantees that Internet number resources > are managed in such a manner that they may be routed on the Internet > in a scalable manner. Nailed it. Very nice. > Routing scalability is necessary to ensure proper operation of > Internet routing, although it must be stressed that routability is in > no way guaranteed with the allocation or assignment of Internet number > resources. Right concept. Could use better words. Maybe merge "Routing scalability is necessary to ensure proper operation of Internet routing," with the previous paragraph and add the then say: ARIN does not make policies about how routing must or must not be done. Allocation or assignment of Internet number resources by ARIN in no way guarantees that those addresses will be routed by any particular Internet service provider. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From billdarte at gmail.com Mon Jul 8 18:26:05 2013 From: billdarte at gmail.com (Bill Darte) Date: Mon, 8 Jul 2013 17:26:05 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DB38C1.70500@umn.edu> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB3707.102@umn.edu> <51DB38C1.70500@umn.edu> Message-ID: I agree in large with what David has suggested. I support the revisions and the draft policy. bd On Mon, Jul 8, 2013 at 5:10 PM, David Farmer wrote: > On 7/8/13 17:02 , David Farmer wrote: > >> My first reaction is I mostly like the update, but I immediately see a >> few nits; >> > > I launched my first reaction a little too soon; more below. > > On 7/8/13 16:34 , ARIN wrote: >> ... >> >>> Draft Policy ARIN-2013-4 >>> RIR Principles >>> >>> Policy Statement (v2 8 July 2013): >>> >>> Section 0: Principles and Goals of the Internet Registry System >>> >>> 0.1. Registration >>> >> >> Both Registration & Conservation are identified as sub-sections 0.1. >> >> The principle of registration guarantees the uniqueness of Internet >>> number resources. >>> >>> Provision of this public registry documenting Internet number resource >>> allocation, reallocation, assignment, and reassignment is necessary: >>> >>> a) to ensure uniqueness and to to provide operational staff with >>> information on who is using each number resource, >>> >> >> There is an implied and between each of these, so make a) a compound >> clause seems unnecessary and somewhat confusing. I'd suggest split a) >> into two, shifting the rest down, proving; >> >> a) to ensure uniqueness, >> b) to provide operational staff with information on who is using each >> number resource, >> >> This provides more punch to a) and just seems cleaner. >> >> b) to provide a contact in case of operational/security problems, >>> c) to provide the transparency required to ensure that Internet number >>> resources are efficiently utilized, and >>> d) to assist in IP allocation studies. >>> >> > It's even worse that I initially saw, the second clause of a) duplicates b) > > so it should be; > > a) to ensure uniqueness, > b) to provide a contact in case of operational/security problems, > c) to provide the transparency required to ensure that Internet number > resources are efficiently utilized, and > d) to assist in IP allocation studies. > > 0.1. Conservation >>> >> >> Again, both Registration & Conservation are identified as sub-sections >> 0.1. I'd suggest making Conservation sub-sections 0.2, and shifting the >> rest down. >> >> ... >> >> > > -- > ==============================**================== > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ==============================**================== > ______________________________**_________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Mon Jul 8 18:45:01 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 8 Jul 2013 16:45:01 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DB38C1.70500@umn.edu> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB3707.102@umn.edu> <51DB38C1.70500@umn.edu> Message-ID: Thanks David, I think those are both good editorial changes that need to be made in any subsequent version. ~Chris On Mon, Jul 8, 2013 at 4:10 PM, David Farmer wrote: > On 7/8/13 17:02 , David Farmer wrote: >> >> My first reaction is I mostly like the update, but I immediately see a >> few nits; > > > I launched my first reaction a little too soon; more below. > > >> On 7/8/13 16:34 , ARIN wrote: >> ... >>> >>> Draft Policy ARIN-2013-4 >>> RIR Principles >>> >>> Policy Statement (v2 8 July 2013): >>> >>> Section 0: Principles and Goals of the Internet Registry System >>> >>> 0.1. Registration >> >> >> Both Registration & Conservation are identified as sub-sections 0.1. >> >>> The principle of registration guarantees the uniqueness of Internet >>> number resources. >>> >>> Provision of this public registry documenting Internet number resource >>> allocation, reallocation, assignment, and reassignment is necessary: >>> >>> a) to ensure uniqueness and to to provide operational staff with >>> information on who is using each number resource, >> >> >> There is an implied and between each of these, so make a) a compound >> clause seems unnecessary and somewhat confusing. I'd suggest split a) >> into two, shifting the rest down, proving; >> >> a) to ensure uniqueness, >> b) to provide operational staff with information on who is using each >> number resource, >> >> This provides more punch to a) and just seems cleaner. >> >>> b) to provide a contact in case of operational/security problems, >>> c) to provide the transparency required to ensure that Internet number >>> resources are efficiently utilized, and >>> d) to assist in IP allocation studies. > > > It's even worse that I initially saw, the second clause of a) duplicates b) > > so it should be; > > a) to ensure uniqueness, > > b) to provide a contact in case of operational/security problems, > c) to provide the transparency required to ensure that Internet number > resources are efficiently utilized, and > d) to assist in IP allocation studies. > >>> 0.1. Conservation >> >> >> Again, both Registration & Conservation are identified as sub-sections >> 0.1. I'd suggest making Conservation sub-sections 0.2, and shifting the >> rest down. >> >> ... >> > > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From ebw at abenaki.wabanaki.net Mon Jul 8 23:09:59 2013 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Mon, 08 Jul 2013 20:09:59 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: <51DB7F07.1030700@abenaki.wabanaki.net> On 7/8/13 3:40 PM, William Herrin wrote: > I think the principle is: sustainable use > of number resources. Conservation is one tool which facilitates > sustainable use in some circumstances. Technical/documented/justified > need is another such tool. Retaining conservation as the core > principle, we'll end up dancing around the stewardship issue a lot > more often that we really ought to. +1. From billdarte at gmail.com Tue Jul 9 08:57:35 2013 From: billdarte at gmail.com (Bill Darte) Date: Tue, 9 Jul 2013 07:57:35 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DB7F07.1030700@abenaki.wabanaki.net> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> Message-ID: To me, the terms are near synonyms, but if anything....sustainable use as it relates to IPv4 suggests that we intend to continue the use of IPv4 in perpetuity....which I am against. Conservation as a principle suggests again to me..that we carefully allocate/assign through technical/documented/justified need until the resource is no longer available or practicable.... Just my gut response to the terms difference. bd On Mon, Jul 8, 2013 at 10:09 PM, Eric Brunner-Williams < ebw at abenaki.wabanaki.net> wrote: > On 7/8/13 3:40 PM, William Herrin wrote: > > I think the principle is: sustainable use > > of number resources. Conservation is one tool which facilitates > > sustainable use in some circumstances. Technical/documented/justified > > need is another such tool. Retaining conservation as the core > > principle, we'll end up dancing around the stewardship issue a lot > > more often that we really ought to. > > +1. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Tue Jul 9 10:16:27 2013 From: bjones at vt.edu (Brian Jones) Date: Tue, 9 Jul 2013 10:16:27 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> Message-ID: On Tue, Jul 9, 2013 at 8:57 AM, Bill Darte wrote: > To me, the terms are near synonyms, but if anything....sustainable use as > it relates to IPv4 suggests that we intend to continue the use of IPv4 in > perpetuity....which I am against. Conservation as a principle suggests > again to me..that we carefully allocate/assign through > technical/documented/justified need until the resource is no longer > available or practicable.... Just my gut response to the terms difference. > > bd > +1 > > > On Mon, Jul 8, 2013 at 10:09 PM, Eric Brunner-Williams < > ebw at abenaki.wabanaki.net> wrote: > >> On 7/8/13 3:40 PM, William Herrin wrote: >> > I think the principle is: sustainable use >> > of number resources. Conservation is one tool which facilitates >> > sustainable use in some circumstances. Technical/documented/justified >> > need is another such tool. Retaining conservation as the core >> > principle, we'll end up dancing around the stewardship issue a lot >> > more often that we really ought to. >> >> +1. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Jul 9 10:25:42 2013 From: bill at herrin.us (William Herrin) Date: Tue, 9 Jul 2013 10:25:42 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> Message-ID: On Tue, Jul 9, 2013 at 8:57 AM, Bill Darte wrote: > To me, the terms are near synonyms, Hi Bill, They're not, as you prove in the rest of the sentence: > but if anything....sustainable use as it > relates to IPv4 suggests that we intend to continue the use of IPv4 in > perpetuity.... Perpetuity, no. Indefinitely, yes. IMO, our job with a given number resource isn't done until the protocols using that resource are abandoned. From where I sit, declaring it over merely because the initial free pool has been exhausted would be rather a gross failure in stewardship. Meh, we did the best we could with conservation. Not our problem any more. See ya! Except it isn't "see ya." With IPv4 depletion we continue registration and are fine-tuning transfer processes. Why are we doing that if the job is not about sustainable use? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ebw at abenaki.wabanaki.net Tue Jul 9 13:00:57 2013 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Tue, 09 Jul 2013 10:00:57 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> Message-ID: <51DC41C9.6000300@abenaki.wabanaki.net> On 7/9/13 5:57 AM, Bill Darte wrote: > ... the terms are near synonyms, but if anything....sustainable use as it > relates to IPv4 suggests that we intend to continue the use of IPv4 in > perpetuity....which I am against. Conservation as a principle > suggests again to me..that we carefully allocate/assign through > technical/documented/justified need until the resource is no longer > available or practicable.... Not everyone hears the same dog whistle. An agency of government delegated some authority relevant to some asset created by government. Could that agency have meant, when making that delegation of authority, that the delegation included the independent disposal of the asset? I don't think the answer to that is "yes". Is conservation of an asset indistinguishable from the use of the asset? Here "use" means allocation of one or more values expressed in 32 bits not otherwise allocated. A conservation goal could be met by ending allocation while one or more values expressed in 32 bits are not otherwise allocated. In simpler terms, turning off the v4 allocation today would satisfy a conservation principle. It would not meet any definition of a use principle that involved any further allocations, from an all-remaining-to-X-tomorrow regime to one-a-day-to-each-X-Y-Z regime. The principles of "conservation" and "allocation" may therefore be distinguished, and "allocation without a definite end" in particular. I'm sure you didn't mean to suggest turning off v4 today, or tomorrow, for large values of tomorrow, but to distinguish between things that are offered as "near synonyms" it is necessary to ask "how do they differ?" Eric From cgrundemann at gmail.com Tue Jul 9 14:19:11 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 9 Jul 2013 12:19:11 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DC41C9.6000300@abenaki.wabanaki.net> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> Message-ID: Hi all, The words used were carefully chosen: "The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources." Let me shed some light on why. Conservation[1] is the act of conserving. It is "the management of human use of natural resources for current public benefit and sustainable social and economic utilization." It is also the "prevention of injury, decay, *waste,* or loss." Sustainability[2], on the other hand, is "the ability to be sustained, supported, upheld, or confirmed." Something is sustainable when it is "able to be maintained" and "capable of being supported." When reviewing the deffinitions of these words we see that conservation is an act or action while sustainability is a state, condition, or quality. Therefor, sustainability is the goal (the desired state) and conservation is the principle (the how) used to meet that goal, hence the wording used. I hope that helps clear up any lingering confusion. Cheers, ~Chris [1] - http://dictionary.reference.com/browse/conservation [2] - http://dictionary.reference.com/browse/sustainability On Tue, Jul 9, 2013 at 11:00 AM, Eric Brunner-Williams wrote: > On 7/9/13 5:57 AM, Bill Darte wrote: >> ... the terms are near synonyms, but if anything....sustainable use as it >> relates to IPv4 suggests that we intend to continue the use of IPv4 in >> perpetuity....which I am against. Conservation as a principle >> suggests again to me..that we carefully allocate/assign through >> technical/documented/justified need until the resource is no longer >> available or practicable.... > > Not everyone hears the same dog whistle. > > An agency of government delegated some authority relevant to some > asset created by government. > > Could that agency have meant, when making that delegation of > authority, that the delegation included the independent disposal of > the asset? I don't think the answer to that is "yes". > > Is conservation of an asset indistinguishable from the use of the > asset? Here "use" means allocation of one or more values expressed in > 32 bits not otherwise allocated. A conservation goal could be met by > ending allocation while one or more values expressed in 32 bits are > not otherwise allocated. In simpler terms, turning off the v4 > allocation today would satisfy a conservation principle. It would not > meet any definition of a use principle that involved any further > allocations, from an all-remaining-to-X-tomorrow regime to > one-a-day-to-each-X-Y-Z regime. The principles of "conservation" and > "allocation" may therefore be distinguished, and "allocation without a > definite end" in particular. > > I'm sure you didn't mean to suggest turning off v4 today, or tomorrow, > for large values of tomorrow, but to distinguish between things that > are offered as "near synonyms" it is necessary to ask "how do they > differ?" > > Eric > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From ebw at abenaki.wabanaki.net Tue Jul 9 15:48:54 2013 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Tue, 09 Jul 2013 12:48:54 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> Message-ID: <51DC6926.8060804@abenaki.wabanaki.net> On 7/9/13 11:19 AM, Chris Grundemann wrote: > I hope that helps clear up any lingering confusion. Probably not. I seem to be stuck in a rut. The purpose of an agency of government in allocating from an asset created by the government was not limited to the momentary authority of the agency, but was, like the authority of the agency, renewable, transferable to other agencies of government, and under defined procedures, delegable. This purpose, neither finite nor infinite, was renewed, transferred and eventually delegated, and our discussion concerns the policies and procedures for allocation, and recovery, of values in a 32 bit range, consistent with the purpose of government at the point of delegation. This purpose forms the "principles" of the delegee, an RIR. I do appreciate you've made the point that "conservation" is a mechanism, possibly non-unique, which may implement the continuing purpose of government of allocation, upon reasonable utility, of routable allocations of identifiers. Equi-Cheers, Eric From bill at herrin.us Tue Jul 9 14:52:47 2013 From: bill at herrin.us (William Herrin) Date: Tue, 9 Jul 2013 14:52:47 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> Message-ID: On Tue, Jul 9, 2013 at 2:19 PM, Chris Grundemann wrote: > The words used were carefully chosen: > Let me shed some light on why. Hi Chris, Thanks for the insight. > Therefor, sustainability is the goal (the desired state) and > conservation is the principle (the how) used to meet that goal, hence > the wording used. I hope that helps clear up any lingering confusion. Now I'll play the "aren't those supposed to be synonymous" card. It seems to me that principles and goals are the same thing: a high level description of the desired state that we intend to ARIN to seek. Policy and procedure then describes "the how." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Tue Jul 9 16:04:03 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 9 Jul 2013 13:04:03 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DC6926.8060804@abenaki.wabanaki.net> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> <51DC6926.8060804@abenaki.wabanaki.net> Message-ID: The question I would ask is: Who cares? IMO government authority is only relevant when determining that the RIRs are properly the steward of all Internet number resources. But when it comes the actual principles of stewardship, those IMO come from the needs of the Internet community, as expressed by those participating in the policy development process. I don't think governmental authority is relevant there at all. -Scott (speaking only for myself) On Tue, Jul 9, 2013 at 12:48 PM, Eric Brunner-Williams < ebw at abenaki.wabanaki.net> wrote: > On 7/9/13 11:19 AM, Chris Grundemann wrote: > > I hope that helps clear up any lingering confusion. > > Probably not. I seem to be stuck in a rut. > > The purpose of an agency of government in allocating from an asset > created by the government was not limited to the momentary authority > of the agency, but was, like the authority of the agency, renewable, > transferable to other agencies of government, and under defined > procedures, delegable. > > This purpose, neither finite nor infinite, was renewed, transferred > and eventually delegated, and our discussion concerns the policies and > procedures for allocation, and recovery, of values in a 32 bit range, > consistent with the purpose of government at the point of delegation. > This purpose forms the "principles" of the delegee, an RIR. > > I do appreciate you've made the point that "conservation" is a > mechanism, possibly non-unique, which may implement the continuing > purpose of government of allocation, upon reasonable utility, of > routable allocations of identifiers. > > Equi-Cheers, > Eric > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebw at abenaki.wabanaki.net Tue Jul 9 21:07:45 2013 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Tue, 09 Jul 2013 18:07:45 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> <51DC6926.8060804@abenaki.wabanaki.net> Message-ID: <51DCB3E1.8040407@abenaki.wabanaki.net> On 7/9/13 1:04 PM, Scott Leibrand wrote: > The question I would ask is: Who cares? Hmm. A trick question. It may depend on what one thinks is at issue, some addresses, or the continuous means to provide routable and unique assignments from some addresses. There are those who advance a view that allocations are private property. There are those who advance a view that some allocations are private property. Both of these views are consistent with a kind of stewardship that leaves the allocation fixed, immutable, and an asset class for which a market can be made. Not that it was any big thing, but having renumbered hq.af.mil some time ago, I think this view is based upon a misunderstanding, the government interest was in some purpose to which numbering, and renumbering, was incidental. Restated, as an agency of government and an allocatee, the interest of a building (Pentagon) tenant in its cable plant and attached devices was not in a specific block of addresses, or even a specific range of addresses, but in the access to the allocation procedures of the Defense Communications Agency. Not a specific slice of pie, just the ability to have a slice of pie. Agencies of government grow, shrink, are absorbed, and are abolished. The interest of government is in the use to which specific allocations of endpoint identifiers, under specific constraints (means of routing, uniqueness of assignment within some scope) are incidental. The indifference of government to persistence of allocation is difficult to reconcile with the private property claims of some non-governmental entities accessing the allocation procedures of the Defense Communications Agency and its successors in interest, presently one or more RIRs. > I don't think governmental authority is relevant there at all. Well, this probably depends on what one thinks the government interest is. The CEO of another 501(c)(3) penned a response to an agency of government's RFP concerning policy which "come[s] from the needs of the Internet community, as expressed by those participating in the policy development process." I thought he offered that the government had little or no present interest and was not surprised by the agency's response. Eric From billdarte at gmail.com Tue Jul 9 21:37:11 2013 From: billdarte at gmail.com (Bill Darte) Date: Tue, 9 Jul 2013 20:37:11 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> Message-ID: I believe these terms are less synonymous. A goal is an objective of pursuit. A principle is a belief system that underlies the actions and makes them consistent with system. bd On Tue, Jul 9, 2013 at 1:52 PM, William Herrin wrote: > On Tue, Jul 9, 2013 at 2:19 PM, Chris Grundemann > wrote: > > The words used were carefully chosen: > > Let me shed some light on why. > > Hi Chris, > > Thanks for the insight. > > > > Therefor, sustainability is the goal (the desired state) and > > conservation is the principle (the how) used to meet that goal, hence > > the wording used. I hope that helps clear up any lingering confusion. > > Now I'll play the "aren't those supposed to be synonymous" card. It > seems to me that principles and goals are the same thing: a high level > description of the desired state that we intend to ARIN to seek. > Policy and procedure then describes "the how." > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From billdarte at gmail.com Tue Jul 9 21:30:15 2013 From: billdarte at gmail.com (Bill Darte) Date: Tue, 9 Jul 2013 20:30:15 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> Message-ID: Bill, IMO we are doing it, first because the replacement protocol was not backward compatible, second because that protocol was not ready soon enough, third because people failed to take the transition seriously, and fourth...because we still need to for the reason mentioned. But, because we need to now does not suggest that we should codify process and practice which entrenches the legacy ever deeper. Still, I admit that this was completely foreseeable and even predictable circumstance. When large scale solutions to any problem are delayed beyond the significant needs of an industry, then point solutions will be sought. And when deployed, they too become legacy by their investments and when the large scale solution finally arrives...it is simply one more point solution. I have witnessed this many times in our industry since 1984. So while I see that it must be what it is....I do not support the thesis that this circumstance is the way it should be and I do not support abandoning the principles that have got us here simply because there is a cry for open market capitalism as the cure all for everything including number resource issues that we face. bd On Tue, Jul 9, 2013 at 9:25 AM, William Herrin wrote: > On Tue, Jul 9, 2013 at 8:57 AM, Bill Darte wrote: > > To me, the terms are near synonyms, > > Hi Bill, > > They're not, as you prove in the rest of the sentence: > > > but if anything....sustainable use as it > > relates to IPv4 suggests that we intend to continue the use of IPv4 in > > perpetuity.... > > Perpetuity, no. Indefinitely, yes. IMO, our job with a given number > resource isn't done until the protocols using that resource are > abandoned. From where I sit, declaring it over merely because the > initial free pool has been exhausted would be rather a gross failure > in stewardship. > > Meh, we did the best we could with conservation. Not our problem any > more. See ya! > > Except it isn't "see ya." With IPv4 depletion we continue registration > and are fine-tuning transfer processes. Why are we doing that if the > job is not about sustainable use? > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From billdarte at gmail.com Tue Jul 9 21:39:16 2013 From: billdarte at gmail.com (Bill Darte) Date: Tue, 9 Jul 2013 20:39:16 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> <51DC6926.8060804@abenaki.wabanaki.net> Message-ID: +1 except that the relevance of government(s) comes into play if the industry cannot adequately govern itself in a way which comes close to a general goodness. bd On Tue, Jul 9, 2013 at 3:04 PM, Scott Leibrand wrote: > The question I would ask is: Who cares? > > IMO government authority is only relevant when determining that the RIRs > are properly the steward of all Internet number resources. But when it > comes the actual principles of stewardship, those IMO come from the needs > of the Internet community, as expressed by those participating in the > policy development process. I don't think governmental authority is > relevant there at all. > > -Scott (speaking only for myself) > > > On Tue, Jul 9, 2013 at 12:48 PM, Eric Brunner-Williams < > ebw at abenaki.wabanaki.net> wrote: > >> On 7/9/13 11:19 AM, Chris Grundemann wrote: >> > I hope that helps clear up any lingering confusion. >> >> Probably not. I seem to be stuck in a rut. >> >> The purpose of an agency of government in allocating from an asset >> created by the government was not limited to the momentary authority >> of the agency, but was, like the authority of the agency, renewable, >> transferable to other agencies of government, and under defined >> procedures, delegable. >> >> This purpose, neither finite nor infinite, was renewed, transferred >> and eventually delegated, and our discussion concerns the policies and >> procedures for allocation, and recovery, of values in a 32 bit range, >> consistent with the purpose of government at the point of delegation. >> This purpose forms the "principles" of the delegee, an RIR. >> >> I do appreciate you've made the point that "conservation" is a >> mechanism, possibly non-unique, which may implement the continuing >> purpose of government of allocation, upon reasonable utility, of >> routable allocations of identifiers. >> >> Equi-Cheers, >> Eric >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Jul 9 22:55:42 2013 From: bill at herrin.us (William Herrin) Date: Tue, 9 Jul 2013 22:55:42 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> Message-ID: On Tue, Jul 9, 2013 at 9:37 PM, Bill Darte wrote: > I believe these terms are less synonymous. A goal is an objective of > pursuit. A principle is a belief system that underlies the actions and > makes them consistent with system. Then perhaps we should ditch the word "principles" and stick with "goals" like RFC 2050 did. By your definition, principles are things like "fairness," and "transparency." "Registration" is not a belief system. The rest aren't much closer to being so. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From billdarte at gmail.com Wed Jul 10 06:59:31 2013 From: billdarte at gmail.com (Bill Darte) Date: Wed, 10 Jul 2013 05:59:31 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> Message-ID: I think in this world, the ditching of principles has always proven to be a poor choice. bd On Tue, Jul 9, 2013 at 9:55 PM, William Herrin wrote: > On Tue, Jul 9, 2013 at 9:37 PM, Bill Darte wrote: > > I believe these terms are less synonymous. A goal is an objective of > > pursuit. A principle is a belief system that underlies the actions and > > makes them consistent with system. > > Then perhaps we should ditch the word "principles" and stick with > "goals" like RFC 2050 did. By your definition, principles are things > like "fairness," and "transparency." "Registration" is not a belief > system. The rest aren't much closer to being so. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Jul 10 08:47:09 2013 From: bill at herrin.us (William Herrin) Date: Wed, 10 Jul 2013 08:47:09 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DB7F07.1030700@abenaki.wabanaki.net> <51DC41C9.6000300@abenaki.wabanaki.net> Message-ID: On Wed, Jul 10, 2013 at 6:59 AM, Bill Darte wrote: > On Tue, Jul 9, 2013 at 9:55 PM, William Herrin wrote: >> Then perhaps we should ditch the word "principles" and stick with >> "goals" like RFC 2050 did. > I think in this world, the ditching of principles has always proven to be a > poor choice. Then fix the draft so that it actually expresses "principles" as you've defined them smart ass. The current draft expresses something else entirely. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From john.sweeting at twcable.com Wed Jul 10 13:54:57 2013 From: john.sweeting at twcable.com (Sweeting, John) Date: Wed, 10 Jul 2013 13:54:57 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: Message-ID: Bill Herrin, you are totally out of line here. Please clean it up, there is no excuse for your rudeness below. Period. On 7/10/13 8:47 AM, "William Herrin" wrote: >On Wed, Jul 10, 2013 at 6:59 AM, Bill Darte wrote: >> On Tue, Jul 9, 2013 at 9:55 PM, William Herrin wrote: > >>> Then perhaps we should ditch the word "principles" and stick with >>> "goals" like RFC 2050 did. > >> I think in this world, the ditching of principles has always proven to >>be a >> poor choice. > >Then fix the draft so that it actually expresses "principles" as >you've defined them smart ass. The current draft expresses something >else entirely. > >Regards, >Bill Herrin > > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From bill at herrin.us Wed Jul 10 16:45:20 2013 From: bill at herrin.us (William Herrin) Date: Wed, 10 Jul 2013 16:45:20 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: You're right John. Bill, I apologize for calling you a smart ass. The draft describes desirable states, not a belief system. Bill defined the former as goals and the latter as principles. Bill then cleverly and deliberately mischaracterized my comment that, if that's so, the draft should be relabelled with the correct word: goals. Clearly I was wrong to view Bill's 'ditching principles' response as a smart-ass remark. And even if it was, it was unforgivably rude for me to have said so. Regards, Bill Herrin On Wed, Jul 10, 2013 at 1:54 PM, Sweeting, John wrote: > Bill Herrin, you are totally out of line here. Please clean it up, there > is no excuse for your rudeness below. Period. > > On 7/10/13 8:47 AM, "William Herrin" wrote: >>On Wed, Jul 10, 2013 at 6:59 AM, Bill Darte wrote: >>> On Tue, Jul 9, 2013 at 9:55 PM, William Herrin wrote: >>>> Then perhaps we should ditch the word "principles" and stick with >>>> "goals" like RFC 2050 did. >> >>> I think in this world, the ditching of principles has always proven to >>>be a >>> poor choice. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From brunner at nic-naa.net Wed Jul 10 20:44:40 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 10 Jul 2013 17:44:40 -0700 Subject: [arin-ppml] Fwd: Last Call: RFC 2050 to historic In-Reply-To: <20130710213959.9266.65720.idtracker@ietfa.amsl.com> References: <20130710213959.9266.65720.idtracker@ietfa.amsl.com> Message-ID: <51DDFFF8.9050502@nic-naa.net> Since this happened to come up recently ... -------- Original Message -------- Subject: Last Call: RFC 2050 to historic Date: Wed, 10 Jul 2013 14:39:59 -0700 From: The IESG Reply-To: ietf at ietf.org To: IETF-Announce The IESG has received a request from an individual participant to make the following status changes: - RFC2050 from Best Current Practice to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-2050-to-historic/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2013-08-07. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The affected document can be obtained via http://datatracker.ietf.org/doc/rfc2050/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-2050-to-historic/ballot/ From billdarte at gmail.com Thu Jul 11 06:49:49 2013 From: billdarte at gmail.com (Bill Darte) Date: Thu, 11 Jul 2013 05:49:49 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: No offense taken....and I assure you that it was not a smart ass comment, but a somewhat cynical observation of history. But I do not see how you continue to suggest that the principles of rfc 2050 are not just that. Conservation is a principle which has as its goal longevity of address availability. Routability is a principle which help preserve proper functioning of the Internet mesh, a goal. And Registration as a principle has as its goal the unique usage of numbers. I believe that they are principles upon which our goals have been pinned and have been effective in my opinion. bd On Wed, Jul 10, 2013 at 3:45 PM, William Herrin wrote: > You're right John. Bill, I apologize for calling you a smart ass. > > The draft describes desirable states, not a belief system. Bill > defined the former as goals and the latter as principles. Bill then > cleverly and deliberately mischaracterized my comment that, if that's > so, the draft should be relabelled with the correct word: goals. > > Clearly I was wrong to view Bill's 'ditching principles' response as a > smart-ass remark. And even if it was, it was unforgivably rude for me > to have said so. > > Regards, > Bill Herrin > > > On Wed, Jul 10, 2013 at 1:54 PM, Sweeting, John > wrote: > > Bill Herrin, you are totally out of line here. Please clean it up, there > > is no excuse for your rudeness below. Period. > > > > On 7/10/13 8:47 AM, "William Herrin" wrote: > >>On Wed, Jul 10, 2013 at 6:59 AM, Bill Darte wrote: > >>> On Tue, Jul 9, 2013 at 9:55 PM, William Herrin wrote: > >>>> Then perhaps we should ditch the word "principles" and stick with > >>>> "goals" like RFC 2050 did. > >> > >>> I think in this world, the ditching of principles has always proven to > >>>be a > >>> poor choice. > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Thu Jul 11 10:39:28 2013 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 11 Jul 2013 10:39:28 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: I see conservation not as a principle, I mean really the guiding principle should have been distribution of addresses, not conservation of them. The goal was to grow the Internet through the dissemination of addresses. Conservation was not the principle, it was the means to prevent the emptying of the free pool by bad actors. These recent incarnations of this proposal continue to try to shoehorn conservation as a principle, even to the point of including conservation inside registration. I don?t think it is either a principal or a goal, for that matter, just a protective mechanism for free pool addresses. With the exhaustion of the free pool, conservation has no place in the NRPM. Until that time, we don?t need to clutter the NRPM with some hoary language from another era. I am still against the proposal. Regards, Mike Burns From: Bill Darte Sent: Thursday, July 11, 2013 6:49 AM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised No offense taken....and I assure you that it was not a smart ass comment, but a somewhat cynical observation of history. But I do not see how you continue to suggest that the principles of rfc 2050 are not just that. Conservation is a principle which has as its goal longevity of address availability. Routability is a principle which help preserve proper functioning of the Internet mesh, a goal. And Registration as a principle has as its goal the unique usage of numbers. I believe that they are principles upon which our goals have been pinned and have been effective in my opinion. bd On Wed, Jul 10, 2013 at 3:45 PM, William Herrin wrote: You're right John. Bill, I apologize for calling you a smart ass. The draft describes desirable states, not a belief system. Bill defined the former as goals and the latter as principles. Bill then cleverly and deliberately mischaracterized my comment that, if that's so, the draft should be relabelled with the correct word: goals. Clearly I was wrong to view Bill's 'ditching principles' response as a smart-ass remark. And even if it was, it was unforgivably rude for me to have said so. Regards, Bill Herrin On Wed, Jul 10, 2013 at 1:54 PM, Sweeting, John wrote: > Bill Herrin, you are totally out of line here. Please clean it up, there > is no excuse for your rudeness below. Period. > > On 7/10/13 8:47 AM, "William Herrin" wrote: >>On Wed, Jul 10, 2013 at 6:59 AM, Bill Darte wrote: >>> On Tue, Jul 9, 2013 at 9:55 PM, William Herrin wrote: >>>> Then perhaps we should ditch the word "principles" and stick with >>>> "goals" like RFC 2050 did. >> >>> I think in this world, the ditching of principles has always proven to >>>be a >>> poor choice. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -------------------------------------------------------------------------------- _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Jul 11 10:52:09 2013 From: bill at herrin.us (William Herrin) Date: Thu, 11 Jul 2013 10:52:09 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 6:49 AM, Bill Darte wrote: > No offense taken....and I assure you that it was not a smart ass comment, > but a somewhat cynical observation of history. But I do not see how you > continue to suggest that the principles of rfc 2050 are not just that. Hi Bill, I think my first hint is that RFC 2050 describes the section we're using as our original source material as "goals" rather than "principles." Indeed, the authors used the word "principles" nowhere in the document. > Conservation is a principle which has as its goal longevity of address > availability. Conservation is a technique which has maximizing the longevity of the free pool as the goal it serves. You have to do mental contortions with the concept to apply it past the free pool: recycling only serves conservation where it reduces the rate of consumption of the non-renewable resource. > Routability is a principle which help preserve proper > functioning of the Internet mesh, a goal. That we must support the proper functioning of the Internet mesh is belief, a principle. Allocating addresses in a manner which permits scalable routing is an objective, a goal in pursuit of that belief. > And Registration as a principle > has as its goal the unique usage of numbers. Registration is a technique which has unique usage as its goal. ULA's stochastic uniqueness is an alternate technique. Neither is a belief system. > I believe that they are > principles upon which our goals have been pinned and have been effective in > my opinion. I think conflating principles, goals and techniques all together with "stewardship" to sort it out will encourage stewardship to sort it out... regularly instead of just in exceptional cases. And once we get used to overriding goals in the name of stewardship, our "principles" really do get ditched. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Thu Jul 11 11:46:08 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 11 Jul 2013 09:46:08 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns wrote: > I see conservation not as a principle, I mean really the guiding principle > should have been distribution of addresses, not conservation of them. > The goal was to grow the Internet through the dissemination of addresses. > Conservation was not the principle, it was the means to prevent the emptying > of the free pool by bad actors. Not true. As I have pointed out in several fora several times before, conservation of the number space is NOT the same as conservation of a free pool of addresses. The principle here is conservation of the number space - the whole thing, not one arbitrary slice of it. The definition of conservation from the science dictionary may be helpful in illustrating what is meant by conservation of Internet numbers: Conservation is generally held to include the management of human use of natural resources for current public benefit and sustainable social and economic utilization. In this case the resource is the unique Internet number spaces (not just free pools). > These recent incarnations of this proposal continue to try to shoehorn > conservation as a principle, even to the point of including conservation > inside registration. > I don?t think it is either a principal or a goal, for that matter, just a > protective mechanism for free pool addresses. > With the exhaustion of the free pool, conservation has no place in the NRPM. > Until that time, we don?t need to clutter the NRPM with some hoary language > from another era. If I can be so trite as to quote myself: "Understanding that the useful life of IPv4 is far from over (raise your hand if you have used IPv4 for a critical communication in the past 24 hours) makes it quite easy to see that we still have a need to "maximise the lifetime of the public IPv4 address space." In fact, the IANA and RIR free pools have essentially been a buffer protecting us from those who would seek to abuse the public IPv4 address space. As long as there was a reserve of IPv4 addresses, perturbations caused by bad actors could be absorbed to a large extent by doling out "new" addresses into the system under the care of more responsible folks. Now that almost all of the public IPv4 address space has moved from RIR pools into the "wild," there is arguably a much greater need to practice conservation. The loss of the RIR free pool buffer does not mark the end of "the lifetime of the public IPv4 address space" as Tore suggests but rather marks our entry into a new phase of that lifetime where stockpiling and hoarding have become even more dangerous."[1] > I am still against the proposal. As is your right. Cheers, ~Chris [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > Regards, > Mike Burns > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From SRyerse at eclipse-networks.com Thu Jul 11 12:11:29 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 11 Jul 2013 16:11:29 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201368E018B@ENI-MAIL.eclipse-networks.com> I couldn?t have said it better. -1 Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Thursday, July 11, 2013 10:39 AM To: Bill Darte; William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised I see conservation not as a principle, I mean really the guiding principle should have been distribution of addresses, not conservation of them. The goal was to grow the Internet through the dissemination of addresses. Conservation was not the principle, it was the means to prevent the emptying of the free pool by bad actors. These recent incarnations of this proposal continue to try to shoehorn conservation as a principle, even to the point of including conservation inside registration. I don?t think it is either a principal or a goal, for that matter, just a protective mechanism for free pool addresses. With the exhaustion of the free pool, conservation has no place in the NRPM. Until that time, we don?t need to clutter the NRPM with some hoary language from another era. I am still against the proposal. Regards, Mike Burns From: Bill Darte Sent: Thursday, July 11, 2013 6:49 AM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised No offense taken....and I assure you that it was not a smart ass comment, but a somewhat cynical observation of history. But I do not see how you continue to suggest that the principles of rfc 2050 are not just that. Conservation is a principle which has as its goal longevity of address availability. Routability is a principle which help preserve proper functioning of the Internet mesh, a goal. And Registration as a principle has as its goal the unique usage of numbers. I believe that they are principles upon which our goals have been pinned and have been effective in my opinion. bd On Wed, Jul 10, 2013 at 3:45 PM, William Herrin > wrote: You're right John. Bill, I apologize for calling you a smart ass. The draft describes desirable states, not a belief system. Bill defined the former as goals and the latter as principles. Bill then cleverly and deliberately mischaracterized my comment that, if that's so, the draft should be relabelled with the correct word: goals. Clearly I was wrong to view Bill's 'ditching principles' response as a smart-ass remark. And even if it was, it was unforgivably rude for me to have said so. Regards, Bill Herrin On Wed, Jul 10, 2013 at 1:54 PM, Sweeting, John > wrote: > Bill Herrin, you are totally out of line here. Please clean it up, there > is no excuse for your rudeness below. Period. > > On 7/10/13 8:47 AM, "William Herrin" > wrote: >>On Wed, Jul 10, 2013 at 6:59 AM, Bill Darte > wrote: >>> On Tue, Jul 9, 2013 at 9:55 PM, William Herrin > wrote: >>>> Then perhaps we should ditch the word "principles" and stick with >>>> "goals" like RFC 2050 did. >> >>> I think in this world, the ditching of principles has always proven to >>>be a >>> poor choice. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ________________________________ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From cb.list6 at gmail.com Thu Jul 11 12:26:02 2013 From: cb.list6 at gmail.com (cb.list6) Date: Thu, 11 Jul 2013 09:26:02 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: On Jul 11, 2013 8:55 AM, "Chris Grundemann" wrote: > > On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns wrote: > > I see conservation not as a principle, I mean really the guiding principle > > should have been distribution of addresses, not conservation of them. > > The goal was to grow the Internet through the dissemination of addresses. > > Conservation was not the principle, it was the means to prevent the emptying > > of the free pool by bad actors. > > Not true. As I have pointed out in several fora several times before, > conservation of the number space is NOT the same as conservation of a > free pool of addresses. The principle here is conservation of the > number space - the whole thing, not one arbitrary slice of it. > > The definition of conservation from the science dictionary may be > helpful in illustrating what is meant by conservation of Internet > numbers: Conservation is generally held to include the management of > human use of natural resources for current public benefit and > sustainable social and economic utilization. In this case the resource > is the unique Internet number spaces (not just free pools). > > > These recent incarnations of this proposal continue to try to shoehorn > > conservation as a principle, even to the point of including conservation > > inside registration. > > I don?t think it is either a principal or a goal, for that matter, just a > > protective mechanism for free pool addresses. > > With the exhaustion of the free pool, conservation has no place in the NRPM. > > Until that time, we don?t need to clutter the NRPM with some hoary language > > from another era. > > If I can be so trite as to quote myself: > > "Understanding that the useful life of IPv4 is far from over (raise > your hand if you have used IPv4 for a critical communication in the > past 24 hours) makes it quite easy to see that we still have a need to > "maximise the lifetime of the public IPv4 address space." > > In fact, the IANA and RIR free pools have essentially been a buffer > protecting us from those who would seek to abuse the public IPv4 > address space. As long as there was a reserve of IPv4 addresses, > perturbations caused by bad actors could be absorbed to a large extent > by doling out "new" addresses into the system under the care of more > responsible folks. Now that almost all of the public IPv4 address > space has moved from RIR pools into the "wild," there is arguably a > much greater need to practice conservation. The loss of the RIR free > pool buffer does not mark the end of "the lifetime of the public IPv4 > address space" as Tore suggests but rather marks our entry into a new > phase of that lifetime where stockpiling and hoarding have become even > more dangerous."[1] > > > I am still against the proposal. > > As is your right. > Who would benefit from hoarding? Hoarding seems like economic "dumping", there are rules and policies around it, but it has never really occured because the economics are wrong. The market ensures dumping does not occur. Or like the FUD about walmart driving local business out and then jacking up prices after competition is gone, its just fud. People made a big noise about it 20 years ago, not any more. I think the market is only interestes in transactions. Ipv4 addresses are like most cars, they depreciate rapidly so hoarding is not a real thing. And, with google fiber at 77% ipv6 and vzw over 25%, i must say i would no hoard ipv4. But, my ask is, lets not assume hoarding or threats to ipv4 by bad actors unless there is a real case that applies. Afaik, arin brought transfers in to increase efficiency CB > Cheers, > ~Chris > > [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > > > Regards, > > Mike Burns > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > -- > @ChrisGrundemann > http://chrisgrundemann.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Thu Jul 11 12:29:53 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 11 Jul 2013 10:29:53 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 10:28 AM, Mike Burns wrote: > Hi Chris, > > How does the conservation principle, which you assert applies to both free > pool and allocated addresses, deal with the current RSA language which > explicitly prevents ARIN from revoking due to utilization? > > It would seem like the RSA is ignoring a guiding principle of stewardship! > > Regards, > Mike > > > > > > -----Original Message----- From: Chris Grundemann > Sent: Thursday, July 11, 2013 11:46 AM > To: Mike Burns > Cc: Bill Darte ; William Herrin ; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns wrote: >> >> I see conservation not as a principle, I mean really the guiding principle >> should have been distribution of addresses, not conservation of them. >> The goal was to grow the Internet through the dissemination of addresses. >> Conservation was not the principle, it was the means to prevent the >> emptying >> of the free pool by bad actors. > > > Not true. As I have pointed out in several fora several times before, > conservation of the number space is NOT the same as conservation of a > free pool of addresses. The principle here is conservation of the > number space - the whole thing, not one arbitrary slice of it. > > The definition of conservation from the science dictionary may be > helpful in illustrating what is meant by conservation of Internet > numbers: Conservation is generally held to include the management of > human use of natural resources for current public benefit and > sustainable social and economic utilization. In this case the resource > is the unique Internet number spaces (not just free pools). > >> These recent incarnations of this proposal continue to try to shoehorn >> conservation as a principle, even to the point of including conservation >> inside registration. >> I don?t think it is either a principal or a goal, for that matter, just a >> protective mechanism for free pool addresses. >> With the exhaustion of the free pool, conservation has no place in the >> NRPM. >> Until that time, we don?t need to clutter the NRPM with some hoary >> language >> from another era. > > > If I can be so trite as to quote myself: > > "Understanding that the useful life of IPv4 is far from over (raise > your hand if you have used IPv4 for a critical communication in the > past 24 hours) makes it quite easy to see that we still have a need to > "maximise the lifetime of the public IPv4 address space." > > In fact, the IANA and RIR free pools have essentially been a buffer > protecting us from those who would seek to abuse the public IPv4 > address space. As long as there was a reserve of IPv4 addresses, > perturbations caused by bad actors could be absorbed to a large extent > by doling out "new" addresses into the system under the care of more > responsible folks. Now that almost all of the public IPv4 address > space has moved from RIR pools into the "wild," there is arguably a > much greater need to practice conservation. The loss of the RIR free > pool buffer does not mark the end of "the lifetime of the public IPv4 > address space" as Tore suggests but rather marks our entry into a new > phase of that lifetime where stockpiling and hoarding have become even > more dangerous."[1] > >> I am still against the proposal. > > > As is your right. > > Cheers, > ~Chris > > [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > >> Regards, >> Mike Burns > > >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > -- > @ChrisGrundemann > http://chrisgrundemann.com -- @ChrisGrundemann http://chrisgrundemann.com From paul at redbarn.org Thu Jul 11 12:42:17 2013 From: paul at redbarn.org (Paul Vixie) Date: Thu, 11 Jul 2013 09:42:17 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: <51DEE069.8020407@redbarn.org> cb.list6 wrote: > > > > > > > > I am still against the proposal. > > > > As is your right. > > > > Who would benefit from hoarding? > someone with an inventory they'd like to increase the value of. for example, see "california, electricity, enron". > Hoarding seems like economic "dumping", there are rules and policies > around it, but it has never really occured because the economics are > wrong. The market ensures dumping does not occur. > hoarding may seem like dumping to you but that's nobody's assertion here so let's not debate it. > Or like the FUD about walmart driving local business out and then > jacking up prices after competition is gone, its just fud. People made > a big noise about it 20 years ago, not any more. > > I think the market is only interestes in transactions. Ipv4 addresses > are like most cars, they depreciate rapidly so hoarding is not a real > thing. > those statements are fantastically naive. > And, with google fiber at 77% ipv6 and vzw over 25%, i must say i > would no hoard ipv4. > well, that's you. > But, my ask is, lets not assume hoarding or threats to ipv4 by bad > actors unless there is a real case that applies. > that argument often accompanies proposals involving deregulation. the invisible hand of the market sometimes does a lot of public harm before it's restrainted. see "greenhouse gas effect". let's instead use sound judgement when deciding our policies. > Afaik, arin brought transfers in to increase efficiency > indeed so, and if that goal hasn't been met, then by all means let's continue fine tuning the transfer mechanism. vixie From mike at nationwideinc.com Thu Jul 11 12:46:53 2013 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 11 Jul 2013 12:46:53 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DEE069.8020407@redbarn.org> References: <51DEE069.8020407@redbarn.org> Message-ID: <3DE1863941E045A187DCC720A8FE2F9A@MPC> > Afaik, arin brought transfers in to increase efficiency > indeed so, and if that goal hasn't been met, then by all means let's continue fine tuning the transfer mechanism. vixie +1 on tuning the transfer mechanism in the face of those who pooh-pooh it as rearranging Titanic's deck chairs. We all know about IPv6. MIke From ebw at abenaki.wabanaki.net Thu Jul 11 13:06:56 2013 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Thu, 11 Jul 2013 10:06:56 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: <51DEE630.7070209@abenaki.wabanaki.net> On 7/11/13 9:26 AM, cb.list6 wrote: > Who would benefit from hoarding? Many. > Hoarding seems like economic "dumping", there are rules and policies > around it, but it has never really occured because the economics are > wrong. The market ensures dumping does not occur. Before embarking on a law and economics discourse it would be useful if you could suggest you are capable of conducting it to a conclusion consistent with your initial offerings, informed by and answering adequately critical commentary. > Or like the FUD about walmart driving local business out and then > jacking up prices after competition is gone, its just fud. People made > a big noise about it 20 years ago, not any more. Could we not segway from a range of ints to some other subject. > I think the market is only interestes in transactions. Ipv4 addresses > are like most cars, they depreciate rapidly so hoarding is not a real > thing. Thought is nice, proof is better. There are numbers, they go the other way. > And, with google fiber at 77% ipv6 and vzw over 25%, i must say i > would no hoard ipv4. The relevance of your point of view may have local scope. > But, my ask is, lets not assume hoarding or threats to ipv4 by bad > actors unless there is a real case that applies. Fine. A condition previously met. > Afaik, arin brought transfers in to increase efficiency Possibly, though efficiency in what is open to interpretation. Eric From mike at nationwideinc.com Thu Jul 11 13:14:58 2013 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 11 Jul 2013 13:14:58 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DEE630.7070209@abenaki.wabanaki.net> References: <51DEE630.7070209@abenaki.wabanaki.net> Message-ID: <8FD18BBEABB54B34864E60378B9B931E@MPC> > But, my ask is, lets not assume hoarding or threats to ipv4 by bad > actors unless there is a real case that applies. Fine. A condition previously met. Hi Eric, I am unclear what you are saying in the above exchange. Are you saying that a real case applies? If so, could you provide details? Or are you saying it's fine to not assume that hoarding will occur? Thanks for any clarification. Regards, Mike From farmer at umn.edu Thu Jul 11 13:28:06 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 11 Jul 2013 12:28:06 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: <51DEEB26.4070204@umn.edu> On 7/8/13 17:40 , William Herrin wrote: ... >> 0.2. Routability >> >> The principle of routability guarantees that Internet number resources >> are managed in such a manner that they may be routed on the Internet >> in a scalable manner. > > Nailed it. Very nice. > >> Routing scalability is necessary to ensure proper operation of >> Internet routing, although it must be stressed that routability is in >> no way guaranteed with the allocation or assignment of Internet number >> resources. > > Right concept. Could use better words. Maybe merge "Routing > scalability is necessary to ensure proper operation of Internet > routing," with the previous paragraph and add the then say: > > ARIN does not make policies about how routing must or must not be > done. Allocation or assignment of Internet number resources by ARIN in > no way guarantees that those addresses will be routed by any > particular Internet service provider. How about; 0.3. Routability The principle of routability guarantees that Internet number resources are managed in such a manner that they may be routed on the Internet in a scalable manner. Routability is maintained by ensuring that growth from unique non-aggregatable allocations or assignments does not exceed the growth in the capabilities of currently available technologies, over time and at particular point in time. Routability is concerned with the Internet as a whole, and provides no guarantee any individual allocation or assignment is entitled to or will be routed on the Internet. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From mike at nationwideinc.com Thu Jul 11 13:45:16 2013 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 11 Jul 2013 13:45:16 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: <80EA344751C14E43A79D081CACBED312@MPC> This is however a solid observation, and I have a couple items for consideration in response: 1) Conservation is not the only guiding principle listed here for a reason, the principle of stewardship is in large part needed to balance the set of guiding principles. 2) ARIN (as a community) has chosen to go down the transfers path rather than the reclamation path, both can serve conservation if properly managed. Cheers, ~Chris I say that conservation as effected through RIR policies have never been directed at the utilization of allocated addresses, except in the context of additional free pool allocations. Considering that as stewards we were charged with growing and sustaining the Internet, it made absolute sense to try to get as many addresses allocated as possible, constrained only by the need to protect the free pool from bad actors. Thus the decision not to charge for free pool addresses, but instead dole them out for free to those who merely had to demonstrate a need. It makes no sense to me to try to retrospectively dismantle this "light touch" distribution system and replace it with one which seems to require an ongoing audit/revokation mechanism to fully comply with this supposed principle, especially in light of the natural conservation provided by a priced transfer market. Regards, Mike From cgrundemann at gmail.com Thu Jul 11 13:58:55 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 11 Jul 2013 11:58:55 -0600 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] Message-ID: On Thu, Jul 11, 2013 at 11:45 AM, Mike Burns wrote: > This is however a solid observation, and I have a couple items for > consideration in response: > > 1) Conservation is not the only guiding principle listed here for a > reason, the principle of stewardship is in large part needed to > balance the set of guiding principles. > 2) ARIN (as a community) has chosen to go down the transfers path > rather than the reclamation path, both can serve conservation if > properly managed. > > Cheers, > ~Chris > > > I say that conservation as effected through RIR policies have never been > directed at the utilization of allocated addresses, except in the context of > additional free pool allocations. That should read "except in the context of additional allocations." The free pool has nothing to do with it. Really. If you want more addresses (from any source) it seems perfectly reasonable to ensure that all the other addresses you have are actually being used, if they are not, you don't need more addresses. This feels like common sense to me. > Considering that as stewards we were charged with growing and sustaining the > Internet, it made absolute sense to try to get as many addresses allocated > as possible, constrained only by the need to protect the free pool from bad Again, the constraint was and is protection of the number space, you are elevating the free pool to an unwarranted level of attention in order to claim that the principle disappears with the free pool. The fact remains that we are discussing conservation of the entire Internet number space(s) and have never been explicitly limited to conservation of the free pool. In fact, conservation of the free pool is antithetical to conservation of the number resource as a whole because our goal is efficient utilization, not maintaining a perpetual free pool. > actors. Thus the decision not to charge for free pool addresses, but instead > dole them out for free to those who merely had to demonstrate a need. It > makes no sense to me to try to retrospectively dismantle this "light touch" > distribution system and replace it with one which seems to require an > ongoing audit/revokation mechanism to fully comply with this supposed I have not seen anyone propose that we dismantle the existing paradigm (save those who wish to drop needs assessments completely) nor anyone proposing a new ongoing audit and revocation mechanism. Let's stick to the facts and proposals that are on the table, I'm passionately against the slaughter of unicorns but I doubt that's relevant to this discussion... > principle, especially in light of the natural conservation provided by a > priced transfer market. > > Regards, > Mike > > > > > -- @ChrisGrundemann http://chrisgrundemann.com From cb.list6 at gmail.com Thu Jul 11 13:26:53 2013 From: cb.list6 at gmail.com (cb.list6) Date: Thu, 11 Jul 2013 10:26:53 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DEE630.7070209@abenaki.wabanaki.net> References: <51DEE630.7070209@abenaki.wabanaki.net> Message-ID: On Jul 11, 2013 10:08 AM, "Eric Brunner-Williams" wrote: > > On 7/11/13 9:26 AM, cb.list6 wrote: > > Who would benefit from hoarding? > > Many. > > > Hoarding seems like economic "dumping", there are rules and policies > > around it, but it has never really occured because the economics are > > wrong. The market ensures dumping does not occur. > > Before embarking on a law and economics discourse it would be useful > if you could suggest you are capable of conducting it to a conclusion > consistent with your initial offerings, informed by and answering > adequately critical commentary. > Really? CB > > Or like the FUD about walmart driving local business out and then > > jacking up prices after competition is gone, its just fud. People made > > a big noise about it 20 years ago, not any more. > > Could we not segway from a range of ints to some other subject. > > > I think the market is only interestes in transactions. Ipv4 addresses > > are like most cars, they depreciate rapidly so hoarding is not a real > > thing. > > Thought is nice, proof is better. There are numbers, they go the other > way. > > > And, with google fiber at 77% ipv6 and vzw over 25%, i must say i > > would no hoard ipv4. > > The relevance of your point of view may have local scope. > > > But, my ask is, lets not assume hoarding or threats to ipv4 by bad > > actors unless there is a real case that applies. > > Fine. A condition previously met. > > > Afaik, arin brought transfers in to increase efficiency > > Possibly, though efficiency in what is open to interpretation. > > Eric > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at nationwideinc.com Thu Jul 11 14:32:27 2013 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 11 Jul 2013 14:32:27 -0400 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: References: Message-ID: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> >> I say that conservation as effected through RIR policies have never been> >> directed at the utilization of allocated addresses, except in the context >> of > additional free pool allocations. >That should read "except in the context of additional allocations." The free pool has nothing to do with it. Really. If you want more addresses (from any source) it seems perfectly reasonable to ensure that all the other addresses you have are actually being used, if they are not, you don't need more addresses. This feels like common sense to me. That's right, the only time utilization was considered was in the allocation of new addresses, but if there truly is a conservation principle that applied to the entire address space, then we should not have specifically said that we would *not* consider utilization in the RSA. To me it is entirely unreasonable for stewards to extend their grasp beyond what is minimally required. Really, the free pool has everything to do with conservation in RFC-2050, as did RFC-2050's language about transfers, which was in place to protect the free pool from repeated allocation/transfer cycles by bad actors. >> Considering that as stewards we were charged with growing and sustaining >> the > Internet, it made absolute sense to try to get as many addresses allocated > as possible, constrained only by the need to protect the free pool from > bad >Again, the constraint was and is protection of the number space, you are elevating the free pool to an unwarranted level of attention in order to claim that the principle disappears with the free pool. The fact remains that we are discussing conservation of the entire Internet number space(s) and have never been explicitly limited to conservation of the free pool. In fact, conservation of the free pool is antithetical to conservation of the number resource as a whole because our goal is efficient utilization, not maintaining a perpetual free pool. IMO, you are erroneously elevating the allocated pool to a level which requires some foggy conservation principle be applied to it, which the RSA seems to ignore. I am describing the thought processes that went into the writing of the RFC-2050, why conservation was necessary, and why it only applies to unpriced addresses. You continue to claim that what we are discussing is the conservation of the entire Internet space, but that is merely an assertion on your part. Your last sentence there makes no sense if you contemplate bad actors accessing a free pool with no conservation principle attached. >I have not seen anyone propose that we dismantle the existing paradigm (save those who wish to drop needs assessments completely) nor anyone proposing a new ongoing audit and revocation mechanism. Let's stick to the facts and proposals that are on the table, I'm passionately against the slaughter of unicorns but I doubt that's relevant to this discussion... You are the one proposing change here. And even though there are not currently any proposals on the table to begin auditing and revokations, the placement of the conservation principle in the NRPM with the assertion that it covers all addresses will act to bolster any such pending proposal. That's why I am opposed to the proposal. Regards, Mike From billdarte at gmail.com Thu Jul 11 14:43:29 2013 From: billdarte at gmail.com (Bill Darte) Date: Thu, 11 Jul 2013 13:43:29 -0500 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: References: Message-ID: The belief system from which the principles of 2050 seem to spring is that....a public resource like IP addresses should be made available to those who need them in as fair and equitable manner as possible in a way that aids the expansion of the Internet.....the way that is done is through public policy in this region through and RIR system founded upon those principles and created by all those wishing to be part of the process. That too seems obvious. That the policies are unfair or obsolete is indeed up to the discretion of those involved at least for the time being. bd On Thu, Jul 11, 2013 at 12:58 PM, Chris Grundemann wrote: > On Thu, Jul 11, 2013 at 11:45 AM, Mike Burns > wrote: > > This is however a solid observation, and I have a couple items for > > consideration in response: > > > > 1) Conservation is not the only guiding principle listed here for a > > reason, the principle of stewardship is in large part needed to > > balance the set of guiding principles. > > 2) ARIN (as a community) has chosen to go down the transfers path > > rather than the reclamation path, both can serve conservation if > > properly managed. > > > > Cheers, > > ~Chris > > > > > > I say that conservation as effected through RIR policies have never been > > directed at the utilization of allocated addresses, except in the > context of > > additional free pool allocations. > > That should read "except in the context of additional allocations." > The free pool has nothing to do with it. Really. If you want more > addresses (from any source) it seems perfectly reasonable to ensure > that all the other addresses you have are actually being used, if they > are not, you don't need more addresses. This feels like common sense > to me. > > > Considering that as stewards we were charged with growing and sustaining > the > > Internet, it made absolute sense to try to get as many addresses > allocated > > as possible, constrained only by the need to protect the free pool from > bad > > Again, the constraint was and is protection of the number space, you > are elevating the free pool to an unwarranted level of attention in > order to claim that the principle disappears with the free pool. The > fact remains that we are discussing conservation of the entire > Internet number space(s) and have never been explicitly limited to > conservation of the free pool. In fact, conservation of the free pool > is antithetical to conservation of the number resource as a whole > because our goal is efficient utilization, not maintaining a perpetual > free pool. > > > actors. Thus the decision not to charge for free pool addresses, but > instead > > dole them out for free to those who merely had to demonstrate a need. It > > makes no sense to me to try to retrospectively dismantle this "light > touch" > > distribution system and replace it with one which seems to require an > > ongoing audit/revokation mechanism to fully comply with this supposed > > I have not seen anyone propose that we dismantle the existing paradigm > (save those who wish to drop needs assessments completely) nor anyone > proposing a new ongoing audit and revocation mechanism. Let's stick to > the facts and proposals that are on the table, I'm passionately > against the slaughter of unicorns but I doubt that's relevant to this > discussion... > > > principle, especially in light of the natural conservation provided by a > > priced transfer market. > > > > Regards, > > Mike > > > > > > > > > > > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Jul 11 15:03:05 2013 From: bill at herrin.us (William Herrin) Date: Thu, 11 Jul 2013 15:03:05 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DEEB26.4070204@umn.edu> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> <51DEEB26.4070204@umn.edu> Message-ID: On Thu, Jul 11, 2013 at 1:28 PM, David Farmer wrote: > How about; > > 0.3. Routability > > > The principle of routability guarantees that Internet number resources are > managed in such a manner that they may be routed on the Internet in a > scalable manner. > > Routability is maintained by ensuring that growth from unique > non-aggregatable allocations or assignments does not exceed the growth in > the capabilities of currently available technologies, over time and at > particular point in time. > > Routability is concerned with the Internet as a whole, and provides no > guarantee any individual allocation or assignment is entitled to or will be > routed on the Internet. Gut reaction: I like it. It says everything on the subject I think ARIN should concern itself with and nothing more. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jschiller at google.com Thu Jul 11 13:27:48 2013 From: jschiller at google.com (Jason Schiller) Date: Thu, 11 Jul 2013 13:27:48 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: Be careful to define what you mean by hording... One might consider acquiring enough IP addresses to maintain current growth (or even greater than current growth due to some hypothetical, yet to be released wiz-bang product), for the period of time until wide spread IPv6 adoption an insurance policy, and good business. Being conservative in risk, one might guess wide spread IPv6 adoption will safely happen in less than 25 years. (it is better to be over by 5 years than under by 5 years) Based on the current justified need of two years projected growth based on data from growth in the last year, this could be considered hording in two dimensions: 1. a use time horizon of greater than two years 2. a projection that is not based on past growth. The problem is corporations have deferred deploying IPv6 until their IPv4 reserves have been depleted, as there is real cost and risk and no new revenue. If corporations can cheaply purchase IPv4 then they can continue to defer. This means the date by which an organization needs to deploy IPv6 is the day before they run out of (or can no longer cheaply purchase) IPv4. Dual stack transition was supposed to work because everyone would deploy IPv6 before the first organization runs out of IPv4. But we moved the finish line from when the first organizations run out to when each individual organization runs out. Each organization will run out at different times. For organizations whose need for addressing continues to grow, not having IPv4 for available growth puts you at competitive disadvantage to your competition who still has addresses. So organizations that continue to grow need at least enough addresses to cover their growth until wide spread IPv6 adoption, or a longer growth horizon then all their competitors that are growing and competing for the same customer base. WRT to speculation... one might argue that the APNIC region is already out of IPv4, and there is unmet need. If there is underutilized IPv4 addresses, and an ARIN - APNIC inter-RIR transfer policy, why haven't we already seen lots of transfers? __Jason On Thu, Jul 11, 2013 at 12:26 PM, cb.list6 wrote: > > On Jul 11, 2013 8:55 AM, "Chris Grundemann" wrote: > > > > On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns > wrote: > > > I see conservation not as a principle, I mean really the guiding > principle > > > should have been distribution of addresses, not conservation of them. > > > The goal was to grow the Internet through the dissemination of > addresses. > > > Conservation was not the principle, it was the means to prevent the > emptying > > > of the free pool by bad actors. > > > > Not true. As I have pointed out in several fora several times before, > > conservation of the number space is NOT the same as conservation of a > > free pool of addresses. The principle here is conservation of the > > number space - the whole thing, not one arbitrary slice of it. > > > > The definition of conservation from the science dictionary may be > > helpful in illustrating what is meant by conservation of Internet > > numbers: Conservation is generally held to include the management of > > human use of natural resources for current public benefit and > > sustainable social and economic utilization. In this case the resource > > is the unique Internet number spaces (not just free pools). > > > > > These recent incarnations of this proposal continue to try to shoehorn > > > conservation as a principle, even to the point of including > conservation > > > inside registration. > > > I don?t think it is either a principal or a goal, for that matter, > just a > > > protective mechanism for free pool addresses. > > > With the exhaustion of the free pool, conservation has no place in the > NRPM. > > > Until that time, we don?t need to clutter the NRPM with some hoary > language > > > from another era. > > > > If I can be so trite as to quote myself: > > > > "Understanding that the useful life of IPv4 is far from over (raise > > your hand if you have used IPv4 for a critical communication in the > > past 24 hours) makes it quite easy to see that we still have a need to > > "maximise the lifetime of the public IPv4 address space." > > > > In fact, the IANA and RIR free pools have essentially been a buffer > > protecting us from those who would seek to abuse the public IPv4 > > address space. As long as there was a reserve of IPv4 addresses, > > perturbations caused by bad actors could be absorbed to a large extent > > by doling out "new" addresses into the system under the care of more > > responsible folks. Now that almost all of the public IPv4 address > > space has moved from RIR pools into the "wild," there is arguably a > > much greater need to practice conservation. The loss of the RIR free > > pool buffer does not mark the end of "the lifetime of the public IPv4 > > address space" as Tore suggests but rather marks our entry into a new > > phase of that lifetime where stockpiling and hoarding have become even > > more dangerous."[1] > > > > > I am still against the proposal. > > > > As is your right. > > > > Who would benefit from hoarding? > > Hoarding seems like economic "dumping", there are rules and policies > around it, but it has never really occured because the economics are wrong. > The market ensures dumping does not occur. > > Or like the FUD about walmart driving local business out and then jacking > up prices after competition is gone, its just fud. People made a big noise > about it 20 years ago, not any more. > > I think the market is only interestes in transactions. Ipv4 addresses are > like most cars, they depreciate rapidly so hoarding is not a real thing. > > And, with google fiber at 77% ipv6 and vzw over 25%, i must say i would no > hoard ipv4. > > But, my ask is, lets not assume hoarding or threats to ipv4 by bad actors > unless there is a real case that applies. > > Afaik, arin brought transfers in to increase efficiency > > CB > > > Cheers, > > ~Chris > > > > [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > > > > > Regards, > > > Mike Burns > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > > > -- > > @ChrisGrundemann > > http://chrisgrundemann.com > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Thu Jul 11 15:14:49 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 11 Jul 2013 13:14:49 -0600 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> References: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> Message-ID: On Thu, Jul 11, 2013 at 12:32 PM, Mike Burns wrote: > >>> I say that conservation as effected through RIR policies have never been> >>> directed at the utilization of allocated addresses, except in the context of >> >> additional free pool allocations. > > >> That should read "except in the context of additional allocations." > > The free pool has nothing to do with it. Really. If you want more > addresses (from any source) it seems perfectly reasonable to ensure > that all the other addresses you have are actually being used, if they > are not, you don't need more addresses. This feels like common sense > to me. > > That's right, the only time utilization was considered was in the allocation > of new addresses, but if there truly is a conservation principle that > applied to the entire address space, then we should not have specifically > said that we would *not* consider utilization in the RSA. To me it is > entirely unreasonable for stewards to extend their grasp beyond what is > minimally required. Really, the free pool has everything to do with > conservation in RFC-2050, as did RFC-2050's language about transfers, which > was in place to protect the free pool from repeated allocation/transfer > cycles by bad actors. >From RFC 2050: 1) Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space. "Internet address space" != "free pool" >>> Considering that as stewards we were charged with growing and sustaining >>> the >> >> Internet, it made absolute sense to try to get as many addresses allocated >> as possible, constrained only by the need to protect the free pool from >> bad > > >> Again, the constraint was and is protection of the number space, you > > are elevating the free pool to an unwarranted level of attention in > order to claim that the principle disappears with the free pool. The > fact remains that we are discussing conservation of the entire > Internet number space(s) and have never been explicitly limited to > conservation of the free pool. In fact, conservation of the free pool > is antithetical to conservation of the number resource as a whole > because our goal is efficient utilization, not maintaining a perpetual > free pool. > > IMO, you are erroneously elevating the allocated pool to a level which > requires some foggy conservation principle be applied to it, which the RSA > seems to ignore. > I am describing the thought processes that went into the writing of the > RFC-2050, why conservation was necessary, and why it only applies to > unpriced addresses. > You continue to claim that what we are discussing is the conservation of the > entire Internet space, but that is merely an assertion on your part. Your > last sentence there makes no sense if you contemplate bad actors accessing a > free pool with no conservation principle attached. > > > > >> I have not seen anyone propose that we dismantle the existing paradigm > > (save those who wish to drop needs assessments completely) nor anyone > proposing a new ongoing audit and revocation mechanism. Let's stick to > the facts and proposals that are on the table, I'm passionately > against the slaughter of unicorns but I doubt that's relevant to this > discussion... > > You are the one proposing change here. > And even though there are not currently any proposals on the table to begin > auditing and revokations, the placement of the conservation principle in the > NRPM with the assertion that it covers all addresses will act to bolster any > such pending proposal. That's why I am opposed to the proposal. > > Regards, > Mike > > > > -- @ChrisGrundemann http://chrisgrundemann.com From stephen at sprunk.org Thu Jul 11 15:15:06 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 11 Jul 2013 14:15:06 -0500 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> References: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> Message-ID: <51DF043A.9000802@sprunk.org> On 11-Jul-13 13:32, Mike Burns wrote: >> I have not seen anyone propose that we dismantle the existing >> paradigm (save those who wish to drop needs assessments completely) >> nor anyone proposing a new ongoing audit and revocation mechanism. >> Let's stick to the facts and proposals that are on the table, I'm >> passionately against the slaughter of unicorns but I doubt that's >> relevant to this discussion... > > You are the one proposing change here. > And even though there are not currently any proposals on the table to > begin auditing and revokations, the placement of the conservation > principle in the NRPM with the assertion that it covers all addresses > will act to bolster any such pending proposal. That's why I am opposed > to the proposal. We already have a reclamation process; see NRPM 12 and the enabling language in the RSA. ARIN hasn't used it much/any to date except in cases of suspected fraud, which IMHO is a dereliction of its duty, but it _has_ been used. Therefore, any proposal to "begin" using it would be moot. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From mike at nationwideinc.com Thu Jul 11 15:48:43 2013 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 11 Jul 2013 15:48:43 -0400 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: <51DF043A.9000802@sprunk.org> References: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> <51DF043A.9000802@sprunk.org> Message-ID: <7F088CFE4006413FA292CFC45CA8D2E8@MPC> >We already have a reclamation process; see NRPM 12 and the enabling language in the RSA. ARIN hasn't used it much/any to date except in cases of suspected fraud, which IMHO is a dereliction of its duty, but it _has_ been used. Therefore, any proposal to "begin" using it would be moot. Hi Stephen, A boogeyman. ARIN will revoke if you don't pay your bill, though. I have asked on this list for any evidence of ARIN ever revoking addresses for utilization and was met by crickets. Hard to reconcile with a principle which demands conservation of all addresses. Regards, Mike From alh-ietf at tndh.net Thu Jul 11 16:12:49 2013 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 11 Jul 2013 13:12:49 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> I am opposed as written::: Chris Grundemann wrote: > On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns > wrote: > > I see conservation not as a principle, I mean really the guiding > > principle should have been distribution of addresses, not conservation of > them. > > The goal was to grow the Internet through the dissemination of addresses. > > Conservation was not the principle, it was the means to prevent the > > emptying of the free pool by bad actors. > > Not true. As I have pointed out in several fora several times before, > conservation of the number space is NOT the same as conservation of a free > pool of addresses. The principle here is conservation of the number space - > the whole thing, not one arbitrary slice of it. > Conservation is a tool to implement fairness under the stewardship principle. It is not in itself a principle, and it is antithetical to the overall mission of "distribution". > The definition of conservation from the science dictionary may be helpful in > illustrating what is meant by conservation of Internet > numbers: Conservation is generally held to include the management of > human use of natural resources for current public benefit and sustainable > social and economic utilization. In this case the resource is the unique > Internet number spaces (not just free pools). In common use, conservation is the act of withholding a resource for consumption at a future date. Rather than debate which definition to use, why not drop the term altogether? It adds no value, and distracts from the overall goal of establishing a replacement for 2050. > > > These recent incarnations of this proposal continue to try to shoehorn > > conservation as a principle, even to the point of including > > conservation inside registration. > > I don't think it is either a principal or a goal, for that matter, > > just a protective mechanism for free pool addresses. > > With the exhaustion of the free pool, conservation has no place in the > NRPM. > > Until that time, we don't need to clutter the NRPM with some hoary > > language from another era. > > If I can be so trite as to quote myself: > > "Understanding that the useful life of IPv4 is far from over (raise your hand if > you have used IPv4 for a critical communication in the past 24 hours) makes it > quite easy to see that we still have a need to "maximise the lifetime of the > public IPv4 address space." > > In fact, the IANA and RIR free pools have essentially been a buffer protecting > us from those who would seek to abuse the public IPv4 address space. As > long as there was a reserve of IPv4 addresses, perturbations caused by bad > actors could be absorbed to a large extent by doling out "new" addresses > into the system under the care of more responsible folks. Now that almost all > of the public IPv4 address space has moved from RIR pools into the "wild," > there is arguably a much greater need to practice conservation. The loss of > the RIR free pool buffer does not mark the end of "the lifetime of the public > IPv4 address space" as Tore suggests but rather marks our entry into a new > phase of that lifetime where stockpiling and hoarding have become even > more dangerous."[1] I agree with Chris that there is no real distinction between the free pool and the overall space. Stewardship applies to all. That said, 'conservation' itself is not a useful term when applied to the whole. In particular, when applied to the IPv4 space the argument that we are protecting for 'future use' is absurd. Wasting time over how to hoard the last bits is not moving the Internet forward. As I have pointed out before, ARIN needs to return 1 /8's worth of IPv4 to IANA as it was acquired under the pretense of use within 2 years, and as that has not happened, it needs to go back now so that others may use it. ... Once we get to the point of ARIN without a free pool, the discussion about policies and principles will align closer to reality. Tony > > > I am still against the proposal. > > As is your right. > > Cheers, > ~Chris > > [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > > > Regards, > > Mike Burns > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > -- > @ChrisGrundemann > http://chrisgrundemann.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cgrundemann at gmail.com Thu Jul 11 13:28:48 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 11 Jul 2013 11:28:48 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 10:28 AM, Mike Burns wrote: > Hi Chris, > > How does the conservation principle, which you assert applies to both free > pool and allocated addresses, deal with the current RSA language which > explicitly prevents ARIN from revoking due to utilization? Well, a principle doesn't actually "deal" with anything itself, we (people) must deal with things - by following the guidance of our principles... > It would seem like the RSA is ignoring a guiding principle of stewardship! This is however a solid observation, and I have a couple items for consideration in response: 1) Conservation is not the only guiding principle listed here for a reason, the principle of stewardship is in large part needed to balance the set of guiding principles. 2) ARIN (as a community) has chosen to go down the transfers path rather than the reclamation path, both can serve conservation if properly managed. Cheers, ~Chris PS - I don't want to dominate the conversation here, so I'll likely resist replying to further conversational/directed replies and try to stick more to moderation, etc... > Regards, > Mike > > > > > > -----Original Message----- From: Chris Grundemann > Sent: Thursday, July 11, 2013 11:46 AM > To: Mike Burns > Cc: Bill Darte ; William Herrin ; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns wrote: >> >> I see conservation not as a principle, I mean really the guiding principle >> should have been distribution of addresses, not conservation of them. >> The goal was to grow the Internet through the dissemination of addresses. >> Conservation was not the principle, it was the means to prevent the >> emptying >> of the free pool by bad actors. > > > Not true. As I have pointed out in several fora several times before, > conservation of the number space is NOT the same as conservation of a > free pool of addresses. The principle here is conservation of the > number space - the whole thing, not one arbitrary slice of it. > > The definition of conservation from the science dictionary may be > helpful in illustrating what is meant by conservation of Internet > numbers: Conservation is generally held to include the management of > human use of natural resources for current public benefit and > sustainable social and economic utilization. In this case the resource > is the unique Internet number spaces (not just free pools). > >> These recent incarnations of this proposal continue to try to shoehorn >> conservation as a principle, even to the point of including conservation >> inside registration. >> I don?t think it is either a principal or a goal, for that matter, just a >> protective mechanism for free pool addresses. >> With the exhaustion of the free pool, conservation has no place in the >> NRPM. >> Until that time, we don?t need to clutter the NRPM with some hoary >> language >> from another era. > > > If I can be so trite as to quote myself: > > "Understanding that the useful life of IPv4 is far from over (raise > your hand if you have used IPv4 for a critical communication in the > past 24 hours) makes it quite easy to see that we still have a need to > "maximise the lifetime of the public IPv4 address space." > > In fact, the IANA and RIR free pools have essentially been a buffer > protecting us from those who would seek to abuse the public IPv4 > address space. As long as there was a reserve of IPv4 addresses, > perturbations caused by bad actors could be absorbed to a large extent > by doling out "new" addresses into the system under the care of more > responsible folks. Now that almost all of the public IPv4 address > space has moved from RIR pools into the "wild," there is arguably a > much greater need to practice conservation. The loss of the RIR free > pool buffer does not mark the end of "the lifetime of the public IPv4 > address space" as Tore suggests but rather marks our entry into a new > phase of that lifetime where stockpiling and hoarding have become even > more dangerous."[1] > >> I am still against the proposal. > > > As is your right. > > Cheers, > ~Chris > > [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > >> Regards, >> Mike Burns > > >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > -- > @ChrisGrundemann > http://chrisgrundemann.com -- @ChrisGrundemann http://chrisgrundemann.com From SRyerse at eclipse-networks.com Thu Jul 11 16:27:46 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 11 Jul 2013 20:27:46 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> References: < CAC1-dt=+oD22dpf4Fvv1KBmcrGtrt36XtMpCj1-RCOrtOycDyw@mail.gmail.com> <01f601ce7e73$04068cc0$0c13a640$@tndh.net> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> I agree wholeheartedly. I noted in one of Tony's past comments that he said "Originally, the RIRs were intended to "facilitate distribution", not be hoarding gatekeepers." We need to get on with facilitating right sized distributions and stop trying to somehow save IPv4 thru conservation. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tony Hain Sent: Thursday, July 11, 2013 4:13 PM To: 'Chris Grundemann'; 'Mike Burns' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised I am opposed as written::: Chris Grundemann wrote: > On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns > wrote: > > I see conservation not as a principle, I mean really the guiding > > principle should have been distribution of addresses, not > > conservation of > them. > > The goal was to grow the Internet through the dissemination of addresses. > > Conservation was not the principle, it was the means to prevent the > > emptying of the free pool by bad actors. > > Not true. As I have pointed out in several fora several times before, > conservation of the number space is NOT the same as conservation of a > free pool of addresses. The principle here is conservation of the > number space - > the whole thing, not one arbitrary slice of it. > Conservation is a tool to implement fairness under the stewardship principle. It is not in itself a principle, and it is antithetical to the overall mission of "distribution". > The definition of conservation from the science dictionary may be > helpful in > illustrating what is meant by conservation of Internet > numbers: Conservation is generally held to include the management of > human use of natural resources for current public benefit and > sustainable social and economic utilization. In this case the resource > is the unique Internet number spaces (not just free pools). In common use, conservation is the act of withholding a resource for consumption at a future date. Rather than debate which definition to use, why not drop the term altogether? It adds no value, and distracts from the overall goal of establishing a replacement for 2050. > > > These recent incarnations of this proposal continue to try to > > shoehorn conservation as a principle, even to the point of including > > conservation inside registration. > > I don't think it is either a principal or a goal, for that matter, > > just a protective mechanism for free pool addresses. > > With the exhaustion of the free pool, conservation has no place in > > the > NRPM. > > Until that time, we don't need to clutter the NRPM with some hoary > > language from another era. > > If I can be so trite as to quote myself: > > "Understanding that the useful life of IPv4 is far from over (raise > your hand if > you have used IPv4 for a critical communication in the past 24 hours) makes it > quite easy to see that we still have a need to "maximise the lifetime > of the > public IPv4 address space." > > In fact, the IANA and RIR free pools have essentially been a buffer protecting > us from those who would seek to abuse the public IPv4 address space. > As long as there was a reserve of IPv4 addresses, perturbations caused > by bad actors could be absorbed to a large extent by doling out "new" > addresses into the system under the care of more responsible folks. > Now that almost all > of the public IPv4 address space has moved from RIR pools into the "wild," > there is arguably a much greater need to practice conservation. The > loss of > the RIR free pool buffer does not mark the end of "the lifetime of the public > IPv4 address space" as Tore suggests but rather marks our entry into a > new phase of that lifetime where stockpiling and hoarding have become > even more dangerous."[1] I agree with Chris that there is no real distinction between the free pool and the overall space. Stewardship applies to all. That said, 'conservation' itself is not a useful term when applied to the whole. In particular, when applied to the IPv4 space the argument that we are protecting for 'future use' is absurd. Wasting time over how to hoard the last bits is not moving the Internet forward. As I have pointed out before, ARIN needs to return 1 /8's worth of IPv4 to IANA as it was acquired under the pretense of use within 2 years, and as that has not happened, it needs to go back now so that others may use it. ... Once we get to the point of ARIN without a free pool, the discussion about policies and principles will align closer to reality. Tony > > > I am still against the proposal. > > As is your right. > > Cheers, > ~Chris > > [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > > > Regards, > > Mike Burns > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > -- > @ChrisGrundemann > http://chrisgrundemann.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bill at herrin.us Thu Jul 11 15:04:15 2013 From: bill at herrin.us (William Herrin) Date: Thu, 11 Jul 2013 15:04:15 -0400 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 2:43 PM, Bill Darte wrote: > should be made available to > those who need them in as fair and equitable manner as possible in a way > that aids the expansion of the Internet.... Okay, now *that* is a belief system, a principle. If you want to make a statement of *principles*, say *that* and then stop. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Thu Jul 11 16:49:46 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 11 Jul 2013 14:49:46 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> Message-ID: On Thu, Jul 11, 2013 at 2:27 PM, Steven Ryerse wrote: > I agree wholeheartedly. I noted in one of Tony's past comments that he said "Originally, the RIRs were intended to "facilitate distribution", not be hoarding gatekeepers." We need to get on with facilitating right sized distributions and stop trying to somehow save IPv4 thru conservation. OK, this sounds more and more like a semantics debate at this point. Steve and Tony especially seem to be opposed to their own interpretation of what the word conservation means, rather than the actual use here in this proposed text. The use of the term conservation here is to mean "prevention of waste" NOT 'stockpiling in the free pool.' I will point you again to the definition I used earlier: "Conservation is generally held to include the management of human use of natural resources for current public benefit and sustainable social and economic utilization." We are talking about managing the Internet number resources (ASN, IPv4, and IPv6) for public benefit and sustainable utilization. We are NOT talking about preserving the free pool at any cost. This is exactly why I feel the need to correct those folks who are trying to twist this into a free pool issue - it is not. The free pool was a tool used to support conservation, not the other way around. Read the principle statement again: "The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources." Where does that sentence say that we should be "hoarding gatekeepers" or "withholding a resource"? $0.02 ~Chris > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tony Hain > Sent: Thursday, July 11, 2013 4:13 PM > To: 'Chris Grundemann'; 'Mike Burns' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > I am opposed as written::: > > Chris Grundemann wrote: >> On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns >> wrote: >> > I see conservation not as a principle, I mean really the guiding >> > principle should have been distribution of addresses, not >> > conservation > of >> them. >> > The goal was to grow the Internet through the dissemination of > addresses. >> > Conservation was not the principle, it was the means to prevent the >> > emptying of the free pool by bad actors. >> >> Not true. As I have pointed out in several fora several times before, >> conservation of the number space is NOT the same as conservation of a >> free pool of addresses. The principle here is conservation of the >> number space > - >> the whole thing, not one arbitrary slice of it. >> > > Conservation is a tool to implement fairness under the stewardship principle. It is not in itself a principle, and it is antithetical to the overall mission of "distribution". > > >> The definition of conservation from the science dictionary may be >> helpful > in >> illustrating what is meant by conservation of Internet >> numbers: Conservation is generally held to include the management of >> human use of natural resources for current public benefit and >> sustainable social and economic utilization. In this case the resource >> is the unique Internet number spaces (not just free pools). > > In common use, conservation is the act of withholding a resource for consumption at a future date. Rather than debate which definition to use, why not drop the term altogether? It adds no value, and distracts from the overall goal of establishing a replacement for 2050. > >> >> > These recent incarnations of this proposal continue to try to >> > shoehorn conservation as a principle, even to the point of including >> > conservation inside registration. >> > I don't think it is either a principal or a goal, for that matter, >> > just a protective mechanism for free pool addresses. >> > With the exhaustion of the free pool, conservation has no place in >> > the >> NRPM. >> > Until that time, we don't need to clutter the NRPM with some hoary >> > language from another era. >> >> If I can be so trite as to quote myself: >> >> "Understanding that the useful life of IPv4 is far from over (raise >> your > hand if >> you have used IPv4 for a critical communication in the past 24 hours) > makes it >> quite easy to see that we still have a need to "maximise the lifetime >> of > the >> public IPv4 address space." >> >> In fact, the IANA and RIR free pools have essentially been a buffer > protecting >> us from those who would seek to abuse the public IPv4 address space. >> As long as there was a reserve of IPv4 addresses, perturbations caused >> by bad actors could be absorbed to a large extent by doling out "new" >> addresses into the system under the care of more responsible folks. >> Now that almost > all >> of the public IPv4 address space has moved from RIR pools into the "wild," >> there is arguably a much greater need to practice conservation. The >> loss > of >> the RIR free pool buffer does not mark the end of "the lifetime of the > public >> IPv4 address space" as Tore suggests but rather marks our entry into a >> new phase of that lifetime where stockpiling and hoarding have become >> even more dangerous."[1] > > I agree with Chris that there is no real distinction between the free pool and the overall space. Stewardship applies to all. That said, 'conservation' > itself is not a useful term when applied to the whole. In particular, when applied to the IPv4 space the argument that we are protecting for 'future use' is absurd. Wasting time over how to hoard the last bits is not moving the Internet forward. As I have pointed out before, ARIN needs to return 1 /8's worth of IPv4 to IANA as it was acquired under the pretense of use within 2 years, and as that has not happened, it needs to go back now so that others may use it. ... Once we get to the point of ARIN without a free pool, the discussion about policies and principles will align closer to reality. > > Tony > > >> >> > I am still against the proposal. >> >> As is your right. >> >> Cheers, >> ~Chris >> >> [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ >> >> > Regards, >> > Mike Burns >> >> > _______________________________________________ >> > PPML >> > You are receiving this message because you are subscribed to the >> > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > Unsubscribe or manage your mailing list subscription at: >> > http://lists.arin.net/mailman/listinfo/arin-ppml >> > Please contact info at arin.net if you experience any issues. >> >> -- >> @ChrisGrundemann >> http://chrisgrundemann.com >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From bill at herrin.us Thu Jul 11 18:17:08 2013 From: bill at herrin.us (William Herrin) Date: Thu, 11 Jul 2013 18:17:08 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> Message-ID: On Thu, Jul 11, 2013 at 4:49 PM, Chris Grundemann wrote: > Steve and Tony especially seem to be opposed to their own > interpretation of what the word conservation means, rather than the > actual use here in this proposed text. Hi Chris, Doesn't that mean that either (A) Steve and Tony have a reading comprehension problem or (B) the word as used in the proposed text is open to unintended interpretations and should be changed to words which are less so? Just a thought, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ikiris at gmail.com Thu Jul 11 17:17:47 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 11 Jul 2013 16:17:47 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> Message-ID: Agree 100% -Blake On Thu, Jul 11, 2013 at 3:49 PM, Chris Grundemann wrote: > On Thu, Jul 11, 2013 at 2:27 PM, Steven Ryerse > wrote: > > I agree wholeheartedly. I noted in one of Tony's past comments that he > said "Originally, the RIRs were intended to "facilitate distribution", not > be hoarding gatekeepers." We need to get on with facilitating right sized > distributions and stop trying to somehow save IPv4 thru conservation. > > OK, this sounds more and more like a semantics debate at this point. > > Steve and Tony especially seem to be opposed to their own > interpretation of what the word conservation means, rather than the > actual use here in this proposed text. The use of the term > conservation here is to mean "prevention of waste" NOT 'stockpiling in > the free pool.' > > I will point you again to the definition I used earlier: "Conservation > is generally held to include the management of human use of natural > resources for current public benefit and sustainable social and > economic utilization." > > We are talking about managing the Internet number resources (ASN, > IPv4, and IPv6) for public benefit and sustainable utilization. We are > NOT talking about preserving the free pool at any cost. This is > exactly why I feel the need to correct those folks who are trying to > twist this into a free pool issue - it is not. The free pool was a > tool used to support conservation, not the other way around. > > Read the principle statement again: "The principle of conservation > guarantees sustainability of the Internet through efficient > utilization of unique number resources." Where does that sentence say > that we should be "hoarding gatekeepers" or "withholding a resource"? > > $0.02 > ~Chris > > > Steven L Ryerse > > President > > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > > 770.656.1460 - Cell > > 770.399.9099 - Office > > 770.392-0076 - Fax > > > > ? Eclipse Networks, Inc. > > Conquering Complex Networks? > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Tony Hain > > Sent: Thursday, July 11, 2013 4:13 PM > > To: 'Chris Grundemann'; 'Mike Burns' > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - > revised > > > > I am opposed as written::: > > > > Chris Grundemann wrote: > >> On Thu, Jul 11, 2013 at 8:39 AM, Mike Burns > >> wrote: > >> > I see conservation not as a principle, I mean really the guiding > >> > principle should have been distribution of addresses, not > >> > conservation > > of > >> them. > >> > The goal was to grow the Internet through the dissemination of > > addresses. > >> > Conservation was not the principle, it was the means to prevent the > >> > emptying of the free pool by bad actors. > >> > >> Not true. As I have pointed out in several fora several times before, > >> conservation of the number space is NOT the same as conservation of a > >> free pool of addresses. The principle here is conservation of the > >> number space > > - > >> the whole thing, not one arbitrary slice of it. > >> > > > > Conservation is a tool to implement fairness under the stewardship > principle. It is not in itself a principle, and it is antithetical to the > overall mission of "distribution". > > > > > >> The definition of conservation from the science dictionary may be > >> helpful > > in > >> illustrating what is meant by conservation of Internet > >> numbers: Conservation is generally held to include the management of > >> human use of natural resources for current public benefit and > >> sustainable social and economic utilization. In this case the resource > >> is the unique Internet number spaces (not just free pools). > > > > In common use, conservation is the act of withholding a resource for > consumption at a future date. Rather than debate which definition to use, > why not drop the term altogether? It adds no value, and distracts from the > overall goal of establishing a replacement for 2050. > > > >> > >> > These recent incarnations of this proposal continue to try to > >> > shoehorn conservation as a principle, even to the point of including > >> > conservation inside registration. > >> > I don't think it is either a principal or a goal, for that matter, > >> > just a protective mechanism for free pool addresses. > >> > With the exhaustion of the free pool, conservation has no place in > >> > the > >> NRPM. > >> > Until that time, we don't need to clutter the NRPM with some hoary > >> > language from another era. > >> > >> If I can be so trite as to quote myself: > >> > >> "Understanding that the useful life of IPv4 is far from over (raise > >> your > > hand if > >> you have used IPv4 for a critical communication in the past 24 hours) > > makes it > >> quite easy to see that we still have a need to "maximise the lifetime > >> of > > the > >> public IPv4 address space." > >> > >> In fact, the IANA and RIR free pools have essentially been a buffer > > protecting > >> us from those who would seek to abuse the public IPv4 address space. > >> As long as there was a reserve of IPv4 addresses, perturbations caused > >> by bad actors could be absorbed to a large extent by doling out "new" > >> addresses into the system under the care of more responsible folks. > >> Now that almost > > all > >> of the public IPv4 address space has moved from RIR pools into the > "wild," > >> there is arguably a much greater need to practice conservation. The > >> loss > > of > >> the RIR free pool buffer does not mark the end of "the lifetime of the > > public > >> IPv4 address space" as Tore suggests but rather marks our entry into a > >> new phase of that lifetime where stockpiling and hoarding have become > >> even more dangerous."[1] > > > > I agree with Chris that there is no real distinction between the free > pool and the overall space. Stewardship applies to all. That said, > 'conservation' > > itself is not a useful term when applied to the whole. In particular, > when applied to the IPv4 space the argument that we are protecting for > 'future use' is absurd. Wasting time over how to hoard the last bits is not > moving the Internet forward. As I have pointed out before, ARIN needs to > return 1 /8's worth of IPv4 to IANA as it was acquired under the pretense > of use within 2 years, and as that has not happened, it needs to go back > now so that others may use it. ... Once we get to the point of ARIN without > a free pool, the discussion about policies and principles will align closer > to reality. > > > > Tony > > > > > >> > >> > I am still against the proposal. > >> > >> As is your right. > >> > >> Cheers, > >> ~Chris > >> > >> [1] - http://www.circleid.com/posts/20130523_removing_need_at_ripe/ > >> > >> > Regards, > >> > Mike Burns > >> > >> > _______________________________________________ > >> > PPML > >> > You are receiving this message because you are subscribed to the > >> > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> > Unsubscribe or manage your mailing list subscription at: > >> > http://lists.arin.net/mailman/listinfo/arin-ppml > >> > Please contact info at arin.net if you experience any issues. > >> > >> -- > >> @ChrisGrundemann > >> http://chrisgrundemann.com > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Jul 11 19:58:59 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 11 Jul 2013 18:58:59 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> Message-ID: <51DF46C3.9020900@umn.edu> I really don't understand this debate on Conservation. :{ There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." Then others are not willing to concede that anything changes with IPv4 run-out. I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... So how do we move forward? I suggest; 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. 3. Are there other concepts, principles, or goals that were missing? I suggested earlier that there were additional principles we should be looking at. An candidates has come up in the conversation today that I would like to propose; 0.2 Fair Distribution The principle of Fair Distribution is the precept that the fundamental purpose of Internet number resources management is to distributed unique number resources in a fair and impartial manner to entities building and operating networks, for benefit of all Internet users equally, and thereby facilitating the growth and sustainability of the Internet. I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From narten at us.ibm.com Fri Jul 12 00:53:03 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 12 Jul 2013 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201307120453.r6C4r36k001120@rotala.raleigh.ibm.com> Total of 57 messages in the last 7 days. script run at: Fri Jul 12 00:53:03 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.04% | 8 | 16.14% | 89491 | billdarte at gmail.com 17.54% | 10 | 11.76% | 65163 | bill at herrin.us 14.04% | 8 | 13.61% | 75446 | cgrundemann at gmail.com 10.53% | 6 | 8.21% | 45537 | mike at nationwideinc.com 8.77% | 5 | 5.48% | 30355 | ebw at abenaki.wabanaki.net 7.02% | 4 | 5.97% | 33087 | farmer at umn.edu 3.51% | 2 | 8.52% | 47207 | sryerse at eclipse-networks.com 3.51% | 2 | 4.96% | 27488 | cb.list6 at gmail.com 3.51% | 2 | 3.76% | 20817 | info at arin.net 1.75% | 1 | 4.72% | 26178 | ikiris at gmail.com 1.75% | 1 | 4.57% | 25339 | jschiller at google.com 1.75% | 1 | 2.08% | 11541 | bjones at vt.edu 1.75% | 1 | 1.98% | 10976 | stephen at sprunk.org 1.75% | 1 | 1.92% | 10670 | scottleibrand at gmail.com 1.75% | 1 | 1.80% | 9977 | alh-ietf at tndh.net 1.75% | 1 | 1.23% | 6817 | john.sweeting at twcable.com 1.75% | 1 | 1.17% | 6465 | paul at redbarn.org 1.75% | 1 | 1.09% | 6052 | narten at us.ibm.com 1.75% | 1 | 1.03% | 5721 | brunner at nic-naa.net --------+------+--------+----------+------------------------ 100.00% | 57 |100.00% | 554327 | Total From jschiller at google.com Fri Jul 12 11:37:16 2013 From: jschiller at google.com (Jason Schiller) Date: Fri, 12 Jul 2013 11:37:16 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution Message-ID: David, I took the liberty or changing the subject to "Fair Distribution" in order to make this a completely separate thread allowing the other conversation to continue (possibly at a later time) without getting tangled up with this one. Comments in line, __Jason On Thu, Jul 11, 2013 at 7:58 PM, David Farmer wrote: > I really don't understand this debate on Conservation. :{ > > There are some that seem to be claim that conservation is irrelevant with > IPv4 free pool run-out. > > I say so what! We still have IPv6 and ASNs to worry about, and while both > resource pools are GARGANTUAN by comparison, they are not infinite. > Therefore some concept of conservation remains necessary, obviously not > the same concept that we have had in IPv4 for the last 20 years or so. > But, completely eliminating conservation as a concept, principle, or goal, > of how we manage Internet number resources, seems like the proverbial > "throwing the baby out with the bath water." > > Then others are not willing to concede that anything changes with IPv4 > run-out. > > I'll can say I really hope something changes, the focus on conservation > that became necessary in the late '90s for IPv4, has nearly lead to the > abandonment of other principles like the end-to-end model, open > availability of resources (anyone building a network should be able to get > unique addresses), etc... > > So how do we move forward? I suggest; > > 1. Can everyone concede that going forward, conservation is much less > important, but that the need for some concept of conservation doesn't > completely go away either. > > Assuming this is true, then the section on stewardship and balancing allows for the community to find the right level, and modify ARIN policy accordingly. > 2. Lets focus the conversation on other issues for a while, let this cool > down a little, then come back to it after we've cooled down and maybe have > resolved some of the other issues. > > Personally, I'm hoping to see the staff assessment soon, and hoping we can make a list of all the current practices that would be modified if this draft policy is implemented, and try to make sure the community aggress those practices should not change and modify the draft accordingly. > 3. Are there other concepts, principles, or goals that were missing? I > suggested earlier that there were additional principles we should be > looking at. An candidates has come up in the conversation today that I > would like to propose; > > 0.2 Fair Distribution > > The principle of Fair Distribution is the precept that the > fundamental purpose of Internet number resources management is to > distributed unique number resources in a fair and impartial manner > to entities building and operating networks, for benefit of all > Internet users equally, and thereby facilitating the growth and > sustainability of the Internet. > > I would not oppose the suggested text. > I'd make this #2 behind Registration, and I'd suggest Conservation could > follow and ties into this principle through the concepts of "fairness" and > "sustainability" > > I'm not sure ordering matters... These are not stack ranked where the most important principle is followed to the detriment of the others. Hence the section on stewardship and suggestion of balancing. But OK, if the community wants it to be #2 I see no issue. > Thanks > > -- > ==============================**================== > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ==============================**================== > ______________________________**_________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Fri Jul 12 11:49:37 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 12 Jul 2013 15:49:37 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DF46C3.9020900@umn.edu> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><5B9E90747FA2974D 91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com>, <51DF46C3.9020900@umn.edu> Message-ID: I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all - we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them. Bill is right that the word conserve needs to be removed. Sent from my iPhone On Jul 11, 2013, at 7:59 PM, "David Farmer" wrote: > I really don't understand this debate on Conservation. :{ > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > > Then others are not willing to concede that anything changes with IPv4 run-out. > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... > > So how do we move forward? I suggest; > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. > > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. > > 3. Are there other concepts, principles, or goals that were missing? I suggested earlier that there were additional principles we should be looking at. An candidates has come up in the conversation today that I would like to propose; > > 0.2 Fair Distribution > > The principle of Fair Distribution is the precept that the > fundamental purpose of Internet number resources management is to > distributed unique number resources in a fair and impartial manner > to entities building and operating networks, for benefit of all > Internet users equally, and thereby facilitating the growth and > sustainability of the Internet. > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" > > Thanks > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Fri Jul 12 12:13:55 2013 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 12 Jul 2013 16:13:55 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: Message-ID: <855077AC3D7A7147A7570370CA01ECD244EA13@SUEX10-mbx-10.ad.syr.edu> Well said, Bill. I haven't participated in this debate because I don't think it is able to accomplish anything productive. The ARIN NPRM already contains a section (4.1) called "General Principles" for IPv4, and for IPv6 sections 6.3 and 6.4 on "Goals" and "Policy Principles" respectively. I don't agree with everything in those sections, but can move to change them at any time. As I understand it, ARIN 2013-4 is a rather bizarre attempt to indirectly modify the content of an update to RFC 2050 in another venue. No such modification is needed because goals and principles are already fully embedded in the NRPM. Can someone tell me why we are having this conversation? -----Original Message----- I think conflating principles, goals and techniques all together with "stewardship" to sort it out will encourage stewardship to sort it out... regularly instead of just in exceptional cases. And once we get used to overriding goals in the name of stewardship, our "principles" really do get ditched. From Matthew.Wilder at telus.com Fri Jul 12 12:17:36 2013 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Fri, 12 Jul 2013 10:17:36 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><5B9E90747FA2974D 91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com>, <51DF46C3.9020900@umn.edu> Message-ID: In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore. To be clear, IP Address schemes can only be updated so far. As far as I can tell IPv4 address schemes have never extended beyond the initial 32 bits they started off with, and IPv6 also will not change from a 128 bit address length. Granted, CIDR was introduced to IPv4 to extend the timeline for exhaust of IPv4 address resources, but this is exceptional, and not the rule (certainly for the future). And the cost you mention is not a negligible one. Think of the amount of time and energy that has already gone into IPv6 only to approach 2% of global IP traffic on IPv6. I believe it is in the community's best interest to conserve the word conservation in some form. As David said, the conservation of IPv6 resources is going to be much different than conservation of IPv4 resources. By the way, for those not following, there is a push from many member nations of the ITU and others in the international community to redistribute the governance of the internet in their interests. Do not be surprised if the nations gain the ability to allocate IP Address resources to the entities within their borders. In that world, IPv6 exhaust is only a short matter of time. If we can at least embed the concept of conservation of IPv6 resources now in some way, the global community will thank us a generation or two from now. mw On July 12, 2013 at 08:50 AM, "Steven Ryerse" wrote: > I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all - we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them. > Bill is right that the word conserve needs to be removed. > Sent from my iPhone > On Jul 11, 2013, at 7:59 PM, "David Farmer" wrote: > > I really don't understand this debate on Conservation. :{ > > > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > > > > Then others are not willing to concede that anything changes with IPv4 run-out. > > > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... > > > > So how do we move forward? I suggest; > > > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. > > > > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. > > > > 3. Are there other concepts, principles, or goals that were missing? > > I suggested earlier that there were additional principles we should be > > looking at. An candidates has come up in the conversation today that > > I would like to propose; > > > > 0.2 Fair Distribution > > > > The principle of Fair Distribution is the precept that the > > fundamental purpose of Internet number resources management is to > > distributed unique number resources in a fair and impartial manner > > to entities building and operating networks, for benefit of all > > Internet users equally, and thereby facilitating the growth and > > sustainability of the Internet. > > > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" > > > > Thanks > > -- > > ================================================ > > David Farmer Email: farmer at umn.edu > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 1-612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > ================================================ > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jschiller at google.com Fri Jul 12 12:37:20 2013 From: jschiller at google.com (Jason Schiller) Date: Fri, 12 Jul 2013 12:37:20 -0400 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: <7F088CFE4006413FA292CFC45CA8D2E8@MPC> References: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> <51DF043A.9000802@sprunk.org> <7F088CFE4006413FA292CFC45CA8D2E8@MPC> Message-ID: Certainly ARIN has prevented an organization from getting additional space if their currently held space is under utilized (even if it is legacy space). ARIN certainly has used a slow start model, rather than giving potentially overly large allocations / assignments when there is not a good foundation of a year's worth of growth to justify the size block requested. These two practices help to sustain IPv4. The application need based justification to transfers is an attempt to continue these sustainable practices. It sounds like whatever concerns people have about the depletion of the free pool, can also be applied to the depletion of sufficiently large blocks of IPv4 available at a reasonable / affordable price on the transfer market. The only way I see out of this is if there is more that enough supply for everyone to purchase all the addresses they need to sustain their growth until there is wide spread IPv6 adoption. One way to encourage this is to require real IPv6 deployment along with IPv4 transfers. Say require 10% of the customer base to be IPv6 capable prior to approving a transfer, and require a plan to get 40% of the customer base IPv6 capable in one year, and 80% in two years. Choose whatever numbers seem right for the community 1%, 30%, 70%? ___Jason On Thu, Jul 11, 2013 at 3:48 PM, Mike Burns wrote: > > We already have a reclamation process; see NRPM 12 and the enabling >> > language in the RSA. ARIN hasn't used it much/any to date except in > cases of suspected fraud, which IMHO is a dereliction of its duty, but > it _has_ been used. Therefore, any proposal to "begin" using it would > be moot. > > Hi Stephen, > > A boogeyman. > ARIN will revoke if you don't pay your bill, though. > I have asked on this list for any evidence of ARIN ever revoking addresses > for utilization and was met by crickets. > Hard to reconcile with a principle which demands conservation of all > addresses. > > > Regards, > Mike > > > > > ______________________________**_________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Fri Jul 12 12:40:22 2013 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 12 Jul 2013 11:40:22 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><5B9E90747FA2974D 91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com>, <51DF46C3.9020900@umn.edu> Message-ID: <8695009A81378E48879980039EEDAD280128D3619B@MAIL1.polartel.local> >>In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore. >>mw Too late Matt.. I called dibs a couple weeks ago on everything that is left for as soon as the greedmongers push policy through to make it possible. I'm first in line. Kevin From Matthew.Wilder at telus.com Fri Jul 12 12:54:03 2013 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Fri, 12 Jul 2013 10:54:03 -0600 Subject: [arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised] In-Reply-To: References: <5B8CCA3B65324EF08538CFBF4F8F10E7@MPC> <51DF043A.9000802@sprunk.org> <7F088CFE4006413FA292CFC45CA8D2E8@MPC> Message-ID: This is definitely an interesting way of ensuring players are solving their own long term problem as well as short term, which can generally be seen as good for the community as well IMO. The one challenge you will face to this proposal is that not all products and services are created equal. As an ISP in Canada that sells Wireless and Wireline solutions to all markets (Business, Consumer, Partner) we have seen that each case has a different propensity for IPv6 adoption, and certainly a broad mix in whether IPv6 solves the IPv4 depletion problem. For instance, a Consumer Wireless service is fairly predictable in its requirements for connectivity, which means it could be serviced with an IPv6 only connection, with NAT64/DNS64 and 464XLAT for instance. The same cannot be said of an Enterprise client's Internet and WAN services. They will run dual-stack undoubtedly for a long time. In terms more generally applicable at Google, I imagine the same could be said of cloud services across Business and Consumer markets. My point is simply that drivers and implications are different across these markets. In general, I would agree that we all want to see IPv6 adoption across the board regardless of its efficacy to solve the problem of IPv4 address depletion. Just want to throw these thoughts to the community for consideration of policies to the effect Jason has proposed. mw On July 12, 2013 at 09:37 AM Jason Schiller wrote: > Certainly ARIN has prevented an organization from getting additional space? > if?their?currently held space is under utilized (even if it is legacy space). > > ARIN certainly has used a slow start model, rather than giving potentially > overly large allocations /?assignments when there is not a good foundation > of a year's worth of growth to justify the size block requested. > > These two practices help to sustain IPv4.? > > The application need based justification to transfers is an attempt > to continue these sustainable practices. > > It sounds like whatever concerns people have about the?depletion? > of the free pool, can also be applied to the depletion of sufficiently > large blocks of IPv4 available at a?reasonable / affordable price on? > the transfer?market. > > The only way I see out of this is if there is more that enough supply? > for everyone to purchase all the addresses they need to sustain > their growth until there is wide spread IPv6 adoption. > > One way to encourage this is to require real IPv6 deployment along > with IPv4 transfers. ?Say require 10% of the customer base to be IPv6? > capable prior to approving a transfer, and require a plan to get 40%? > of the customer base IPv6 capable in one year, and 80% in two years. > > Choose whatever numbers seem right for the community 1%, 30%, 70%? > > ___Jason > > > On Thu, Jul 11, 2013 at 3:48 PM, Mike Burns wrote: > > We already have a reclamation process; see NRPM 12 and the enabling > language in the RSA. ?ARIN hasn't used it much/any to date except in > cases of suspected fraud, which IMHO is a dereliction of its duty, but > it _has_ been used. ?Therefore, any proposal to "begin" using it would > be moot. > Hi Stephen, > > A boogeyman. > ARIN will revoke if you don't pay your bill, though. > I have asked on this list for any evidence of ARIN ever revoking addresses for utilization and was met by crickets. > Hard to reconcile with a principle which demands conservation of all addresses. > > > Regards, > Mike > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 From mueller at syr.edu Fri Jul 12 12:58:15 2013 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 12 Jul 2013 16:58:15 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <855077AC3D7A7147A7570370CA01ECD244EA13@SUEX10-mbx-10.ad.syr.edu> Message-ID: <855077AC3D7A7147A7570370CA01ECD244EAB3@SUEX10-mbx-10.ad.syr.edu> -----Original Message----- >> As I understand it, ARIN 2013-4 is a rather bizarre attempt to indirectly modify the content of an >>update to RFC 2050 in another venue. No such modification is needed because goals and principles >> are already fully embedded in the NRPM. Can someone tell me why we are having this conversation? >Well, one obvious reason why we are having this conversation is that the current section 4.1 (which you >reference above) contains a pointer to RFC2050, which will soon be deprecated. Rather than lose that >pointer, this policy proposal seeks to codify the most relevant bits of RFC 2050 (the principles as we see >them today) into the NRPM. Meh. IPv4, like 2050, will be deprecated eventually too. I think it's best to keep that reference in there; both are artifacts of an earlier era. Besides, I think it is good to keep the goals and principles applicable to IPv4 and IPv6 distinct. >Another reason is that it would seem to make sense to have a single set of over arching principles for >number resource management by the RIR in one place, and then have IPv4, IPv6, and ASN specifics in >each of those sections. Obviously, I don't agree. We can't agree on the principles, the goals and techniques and principles seem to vary across all 3 of those domains. >Finally, we are having this discussion because many appear to find it relevant and important, as an AC >member discussing proposed policy changes is kind of your thing now. ;-) ;-) Maybe my comments will alter their perception of its relevance and importance. From cgrundemann at gmail.com Fri Jul 12 12:51:44 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 12 Jul 2013 10:51:44 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <855077AC3D7A7147A7570370CA01ECD244EA13@SUEX10-mbx-10.ad.syr.edu> References: <855077AC3D7A7147A7570370CA01ECD244EA13@SUEX10-mbx-10.ad.syr.edu> Message-ID: On Fri, Jul 12, 2013 at 10:13 AM, Milton L Mueller wrote: > Well said, Bill. I haven't participated in this debate because I don't think it is able to accomplish anything productive. The ARIN NPRM already contains a section (4.1) called "General Principles" for IPv4, and for IPv6 sections 6.3 and 6.4 on "Goals" and "Policy Principles" respectively. I don't agree with everything in those sections, but can move to change them at any time. And this is a move to change them... > As I understand it, ARIN 2013-4 is a rather bizarre attempt to indirectly modify the content of an update to RFC 2050 in another venue. No such modification is needed because goals and principles are already fully embedded in the NRPM. Can someone tell me why we are having this conversation? Well, one obvious reason why we are having this conversation is that the current section 4.1 (which you reference above) contains a pointer to RFC2050, which will soon be deprecated. Rather than lose that pointer, this policy proposal seeks to codify the most relevant bits of RFC 2050 (the principles as we see them today) into the NRPM. Another reason is that it would seem to make sense to have a single set of over arching principles for number resource management by the RIR in one place, and then have IPv4, IPv6, and ASN specifics in each of those sections. Finally, we are having this discussion because many appear to find it relevant and important, as an AC member discussing proposed policy changes is kind of your thing now. ;-) Cheers, ~Chris > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From farmer at umn.edu Fri Jul 12 13:18:04 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 12 Jul 2013 12:18:04 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: References: Message-ID: <51E03A4C.4090205@umn.edu> On 7/12/13 10:37 , Jason Schiller wrote: > David, > > I took the liberty or changing the subject to "Fair Distribution" in > order to make this a > completely separate thread allowing the other conversation to continue > (possibly at a later > time) without getting tangled up with this one. Thanks > Comments in line, > > __Jason > > On Thu, Jul 11, 2013 at 7:58 PM, David Farmer > wrote: > ... > So how do we move forward? I suggest; > > 1. Can everyone concede that going forward, conservation is much > less important, but that the need for some concept of conservation > doesn't completely go away either. > > Assuming this is true, then the section on stewardship and balancing > allows for the community to find the right level, and modify ARIN > policy accordingly. Yes, exactly > 2. Lets focus the conversation on other issues for a while, let this > cool down a little, then come back to it after we've cooled down and > maybe have resolved some of the other issues. > > Personally, I'm hoping to see the staff assessment soon, and hoping we > can make a list > of all the current practices that would be modified if this draft policy > is implemented, > and try to make sure the community aggress those practices should not change > and modify the draft accordingly. The AC has a call next week, I'm sure we will discuss this. But, Chris is the Shepherd and I'll let him take the lead on that. > 3. Are there other concepts, principles, or goals that were missing? > I suggested earlier that there were additional principles we > should be looking at. An candidates has come up in the conversation > today that I would like to propose; > > 0.2 Fair Distribution > > The principle of Fair Distribution is the precept that the > fundamental purpose of Internet number resources management is to > distributed unique number resources in a fair and impartial manner > to entities building and operating networks, for benefit of all > Internet users equally, and thereby facilitating the growth and > sustainability of the Internet. > > > I would not oppose the suggested text. I think it probably needs more work, but I'll leave that in Chris' capable hands as shepherd. I just want to start the discussion, I'm interested in what others think too. > I'd make this #2 behind Registration, and I'd suggest Conservation > could follow and ties into this principle through the concepts of > "fairness" and "sustainability" > > > I'm not sure ordering matters... From a technical perspective, no ordering doesn't mater. > These are not stack ranked where the most important principle is followed > to the detriment of the others. Hence the section on stewardship and > suggestion of balancing. > > But OK, if the community wants it to be #2 I see no issue. However, from an emotional perspective and how people interrupt the narrative it does mater. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen at delong.com Fri Jul 12 13:13:58 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 12 Jul 2013 10:13:58 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DF46C3.9020900@umn.edu> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> <51DF46C3.9020900@umn.edu> Message-ID: <4B40157F-397C-4274-B173-131A690B4947@delong.com> On Jul 11, 2013, at 16:58 , David Farmer wrote: > I really don't understand this debate on Conservation. :{ > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > +1 > Then others are not willing to concede that anything changes with IPv4 run-out. > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... I disagree. The scarcity of IPv4 addresses, not the focus on conservation is what lead to the abandonment of end-to-end and the open availability of resources. The principles were not abandoned so much as forced up against a wall where they could not be sustained. This will not change with free-pool runout. It cannot change. It can only get worse. > So how do we move forward? I suggest; > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. No. I think conservation as a core principle as described by Chris G. remains vital and must be retained. > 0.2 Fair Distribution > > The principle of Fair Distribution is the precept that the > fundamental purpose of Internet number resources management is to > distributed unique number resources in a fair and impartial manner > to entities building and operating networks, for benefit of all > Internet users equally, and thereby facilitating the growth and > sustainability of the Internet. > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" If you are going to do that, then a sentence should be added at the beginning indicating that the order in which the principle are stated is arbitrary and not intended to convey their relative importance. Indeed, the relative importance of those principles and the need to balance them shifts with context to some extent and with time to a much larger extent. The balancing of the relative importance of these principles is one of the primary purposes of the PDP IMHO. Owen From bill at herrin.us Fri Jul 12 13:34:19 2013 From: bill at herrin.us (William Herrin) Date: Fri, 12 Jul 2013 13:34:19 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DF46C3.9020900@umn.edu> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> <51DF46C3.9020900@umn.edu> Message-ID: On Thu, Jul 11, 2013 at 7:58 PM, David Farmer wrote: > We still have IPv6 and ASNs to worry about, and while both > resource pools are GARGANTUAN by comparison, they are not infinite. Hi David, While not technically infinite, the 32 bit ASN pool is functionally infinite. There is no foreseeable course of events which would exhaust that pool. Ever. > 1. Can everyone concede that going forward, conservation is much less > important, but that the need for some concept of conservation doesn't > completely go away either. I'd like to, but no. This document applies it to "number resources" not "addresses." Previous documents on the subject (e.g. RFC 2050) correctly limited conservation statements to "addresses." Also, conservation of IPv6 addresses moving forward is neither "much less" important nor even "less" important. It's merely different. We'd like to not burn through that free pool in the next decade or two. It wasn't that long ago that some folks in this forum quite seriously suggested allocating /16's and /15's to ISPs in support of 6rd efforts. Unlike the ASN pool, the IPv6 pool is not functionally infinite. Finally, IPv4 conservation beyond the free pool is moot. One cannot conserve what has already been consumed. Redistribution, in whatever form it takes, is not properly described as conservation. > 3. Are there other concepts, principles, or goals that were missing? Fairness and process integrity through transparency. Touched on it, but if we're describing principles rather than goals it's more centrally important. > 0.2 Fair Distribution > > The principle of Fair Distribution is the precept that the > fundamental purpose of Internet number resources management is to > distributed unique number resources in a fair and impartial manner > to entities building and operating networks, for benefit of all > Internet users equally, and thereby facilitating the growth and > sustainability of the Internet. How does this statement square with the continued existence of two very unequal classes of registrants? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Fri Jul 12 13:53:48 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 12 Jul 2013 11:53:48 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: <51E03A4C.4090205@umn.edu> References: <51E03A4C.4090205@umn.edu> Message-ID: On Fri, Jul 12, 2013 at 11:18 AM, David Farmer wrote: > On 7/12/13 10:37 , Jason Schiller wrote: >> >> David, >> >> I took the liberty or changing the subject to "Fair Distribution" in >> order to make this a >> completely separate thread allowing the other conversation to continue >> (possibly at a later >> time) without getting tangled up with this one. > > > Thanks > >> Comments in line, >> >> __Jason >> >> On Thu, Jul 11, 2013 at 7:58 PM, David Farmer > > wrote: >> > ... >> >> So how do we move forward? I suggest; >> >> 1. Can everyone concede that going forward, conservation is much >> less important, but that the need for some concept of conservation >> doesn't completely go away either. >> >> Assuming this is true, then the section on stewardship and balancing >> allows for the community to find the right level, and modify ARIN >> policy accordingly. > > > Yes, exactly > > >> 2. Lets focus the conversation on other issues for a while, let this >> cool down a little, then come back to it after we've cooled down and >> maybe have resolved some of the other issues. >> >> Personally, I'm hoping to see the staff assessment soon, and hoping we >> can make a list >> of all the current practices that would be modified if this draft policy >> is implemented, >> and try to make sure the community aggress those practices should not >> change >> and modify the draft accordingly. > > > The AC has a call next week, I'm sure we will discuss this. But, Chris is > the Shepherd and I'll let him take the lead on that. As David mentioned, we have a meeting coming up but I can't get the full staff and legal review until we stop changing the text! =) So my guess is that we'll have to do that a bit further down the line. I will tell you that I got an informal/off-the-record assesment from staff and based the v2 text on what I heard. So, the current text is designed to not modify any current practices - we will need to confirm that again once the text congeals. >> 3. Are there other concepts, principles, or goals that were missing? >> I suggested earlier that there were additional principles we >> should be looking at. An candidates has come up in the conversation >> today that I would like to propose; >> >> 0.2 Fair Distribution >> >> The principle of Fair Distribution is the precept that the >> fundamental purpose of Internet number resources management is to >> distributed unique number resources in a fair and impartial manner >> to entities building and operating networks, for benefit of all >> Internet users equally, and thereby facilitating the growth and >> sustainability of the Internet. >> >> >> I would not oppose the suggested text. > > > I think it probably needs more work, but I'll leave that in Chris' capable > hands as shepherd. I just want to start the discussion, I'm interested in > what others think too. I have some ideas on how to work this in, along with some other suggestions that have been made - there will be a v3 of the text, I'm waiting till the conversation settles down before trying to incorporate it all though - stay tuned! Cheers, ~Chris >> I'd make this #2 behind Registration, and I'd suggest Conservation >> could follow and ties into this principle through the concepts of >> "fairness" and "sustainability" >> >> >> I'm not sure ordering matters... > > > From a technical perspective, no ordering doesn't mater. > > >> These are not stack ranked where the most important principle is followed >> to the detriment of the others. Hence the section on stewardship and >> suggestion of balancing. >> >> But OK, if the community wants it to be #2 I see no issue. > > > However, from an emotional perspective and how people interrupt the > narrative it does mater. > > > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From jschiller at google.com Fri Jul 12 16:53:43 2013 From: jschiller at google.com (Jason Schiller) Date: Fri, 12 Jul 2013 16:53:43 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution Message-ID: On Fri, Jul 12, 2013 at 1:34 PM, William Herrin wrote: > On Thu, Jul 11, 2013 at 7:58 PM, David Farmer wrote: > > > > 3. Are there other concepts, principles, or goals that were missing? > > Fairness and process integrity through transparency. Touched on it, > but if we're describing principles rather than goals it's more > centrally important. > > > > 0.2 Fair Distribution > > > > The principle of Fair Distribution is the precept that the > > fundamental purpose of Internet number resources management is to > > distributed unique number resources in a fair and impartial manner > > to entities building and operating networks, for benefit of all > > Internet users equally, and thereby facilitating the growth and > > sustainability of the Internet. > > How does this statement square with the continued existence of two > very unequal classes of registrants? > > IMO, in the past, the community has agreed that those who got legacy address did so under a different set of rules. The LRSA was an attempt to bring them into the fold without forcing them to lose the current legacy addresses they hold. Previous attempts to force them to renumber, consolidate, or return have not been supported, and are even less likely now that they might have value on the market. Going forward, subsequent allocations require efficient utilization of current address space, and legacy space is included in that calculation. Additionally, when a specified transfer happens, the receiving party must justify the need for address, even if it is legacy space. These two rules further reduce the unequalness. To allow transfers with no needs based justification of legacy space is to maintain these two unequal classes, and make the privilege transferrable. Sounds like we have three choices here: 1. remove the inequality - claw back under utilized legacy IPv4 space 2. minimize the inequality - require legacy holders to be efficiently utilized before they get additional space (some legacy holders are growing, and have AIRN space) - hope this minimizes the inequality over time 3. maintain the inequality - Allow legacy addresses to transfer including the right to keep them under utilized Current policy is option 2. This proposal does not seek to change that. __Jason -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Jul 12 17:17:48 2013 From: bill at herrin.us (William Herrin) Date: Fri, 12 Jul 2013 17:17:48 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: References: Message-ID: On Fri, Jul 12, 2013 at 4:53 PM, Jason Schiller wrote: >> > 0.2 Fair Distribution >> > >> > The principle of Fair Distribution is the precept that the >> > fundamental purpose of Internet number resources management is to >> > distributed unique number resources in a fair and impartial manner >> > to entities building and operating networks, for benefit of all >> > Internet users equally, and thereby facilitating the growth and >> > sustainability of the Internet. >> >> How does this statement square with the continued existence of two >> very unequal classes of registrants? >> > IMO, in the past, the community has agreed that those who got legacy address > did so under a different set of rules. Hi Jason, To clarify, I meant ISPs and end users. Though the legacy issue does illustrate the difference between fairness and fair distribution. Grandfathering mechanisms are usually fair but rarely yield a fair distribution. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jschiller at google.com Fri Jul 12 17:26:32 2013 From: jschiller at google.com (Jason Schiller) Date: Fri, 12 Jul 2013 17:26:32 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: References: Message-ID: Bill, Oh. In that case can you be a little more explicit? I have always felt like ISP have a different need than end-sites, and understood the divergence in policy for the two. For example, and ISP should be forced to document when it makes an assignment to a customer, The same requirement doesn't apply to a University who is assigning space to the philosophy department. What differences between ISPs and end-sites do you think are unfair. ___Jason On Fri, Jul 12, 2013 at 5:17 PM, William Herrin wrote: > On Fri, Jul 12, 2013 at 4:53 PM, Jason Schiller > wrote: > >> > 0.2 Fair Distribution > >> > > >> > The principle of Fair Distribution is the precept that the > >> > fundamental purpose of Internet number resources management is to > >> > distributed unique number resources in a fair and impartial manner > >> > to entities building and operating networks, for benefit of all > >> > Internet users equally, and thereby facilitating the growth and > >> > sustainability of the Internet. > >> > >> How does this statement square with the continued existence of two > >> very unequal classes of registrants? > >> > > IMO, in the past, the community has agreed that those who got legacy > address > > did so under a different set of rules. > > Hi Jason, > > To clarify, I meant ISPs and end users. > > Though the legacy issue does illustrate the difference between > fairness and fair distribution. Grandfathering mechanisms are usually > fair but rarely yield a fair distribution. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Jul 12 17:56:05 2013 From: bill at herrin.us (William Herrin) Date: Fri, 12 Jul 2013 17:56:05 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: References: Message-ID: On Fri, Jul 12, 2013 at 5:26 PM, Jason Schiller wrote: > In that case can you be a little more explicit? > > I have always felt like ISP have a different need than end-sites, and > understood the divergence > in policy for the two. > > For example, and ISP should be forced to document when it makes an > assignment to a customer, > The same requirement doesn't apply to a University who is assigning space to > the philosophy department. Hi Jason, Why not? Perhaps not the philosophy department, but why shouldn't addresses assigned for use by students in the dorms be treated the same as ISP assignments to their customers? Why does one class of registrant get to treat its assignments to customer equipment one way while another class of registrants has it harder? Why don't we have one class of customer with two rule sets: report your internal use this way, report your assignments to customer equipment that way. Would that not be more fair? > What differences between ISPs and end-sites do you think are unfair. Votes, for one thing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Sat Jul 13 00:03:42 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 12 Jul 2013 23:03:42 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> <51DF46C3.9020900@umn.edu> Message-ID: <51E0D19E.90209@umn.edu> On 7/12/13 12:34 , William Herrin wrote: > On Thu, Jul 11, 2013 at 7:58 PM, David Farmer wrote: >> We still have IPv6 and ASNs to worry about, and while both >> resource pools are GARGANTUAN by comparison, they are not infinite. > > Hi David, > > While not technically infinite, the 32 bit ASN pool is functionally > infinite. There is no foreseeable course of events which would exhaust > that pool. Ever. As ASNs are currently used, 1 or a very small number of ASNs per organization, they might seem functionally infinite. However, the IETF is about to allocate 94,967,295 Private Use ASNs[1] (AS4,200,000,000 - AS4,294,967,294) which is more than 1400 times the ASNs currently in use. This is intended to facilitate other BGP applications like large scale enterprise use of BGP based MPLS VPNs, or some new data center uses of BGP[2]. Think of an ASN per top of rack or end or row switch in your favorite monster scale Data Center. [1] http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-05 [2] http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-04 In the discussion of expanding Private Use ASNs it was suggested it might be better if blocks (maybe large blocks) of unique public ASNs were assigned to organizations, instead of going the private use route. So, if large blocks of ASNs were to be assigned per organization, then ASNs might not seem so functionally infinite anymore. This is all hypothetical right now, except the nearly 100M Private Use ASNs, that has been approved by the IESG and is in the RFC Editor Queue now. But, if in the future we start using ASNs in different ways than now, and our rate of use changes significantly, then ASNs may not seem so functionally infinite any more. In the mid-80s 4B IP addresses seemed functionally infinite. But, by the mid-90s it was obvious 4B IPs wasn't functionally infinite at all. Is 4B ASNs still going to seem functionally infinite in 2025? I think it will probably still seem functionally infinite, but all I know is things change. >> 1. Can everyone concede that going forward, conservation is much less >> important, but that the need for some concept of conservation doesn't >> completely go away either. > > I'd like to, but no. This document applies it to "number resources" > not "addresses." Previous documents on the subject (e.g. RFC 2050) > correctly limited conservation statements to "addresses." > > Also, conservation of IPv6 addresses moving forward is neither "much > less" important nor even "less" important. It's merely different. "Much less" is in comparison to other issues for IPv6, conservation is much less important than routability for IPv6 in my opinion. > We'd like to not burn through that free pool in the next decade or > two. It wasn't that long ago that some folks in this forum quite > seriously suggested allocating /16's and /15's to ISPs in support of > 6rd efforts. People say lots of things, I don't think anyone really thought a /16 for 6rd per ISP was reasonable. One reason was conservation. > Unlike the ASN pool, the IPv6 pool is not functionally > infinite. I believe some form of conservation is applicable for all "number resources", even ASNs. Again, are ASNs going to seem functionally infinite in 2025? Also, similar to Matthew requesting a /8 of IPv6 earlier today; If we don't need conservation for ASNs then I'll take a million ASNs please. I've provided what I think is a plausible situation where conservation applied to ASNs could be beneficial. Can you provide a plausible situation where conservation applied to ASNs could be harmful? > Finally, IPv4 conservation beyond the free pool is moot. One cannot > conserve what has already been consumed. Redistribution, in whatever > form it takes, is not properly described as conservation. The definitions I'm thinking of; Conservation - Noun - The action of conserving something, in particular. Conserving - Verb - Prevent the wasteful or harmful overuse of (a resource). A Hypothetical; Is it in the interest of Internet for a bankruptcy trustee to sell IPv4 addresses to a snow shoe spammer? How is something like this prevented without a concept of conservation for IPv4? Personally, I don't have to use the "C" word, but the interconnected meaning of a lot of the concepts we are talking about boil down to the same or only subtly different things. ... -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen at delong.com Sat Jul 13 01:17:22 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 12 Jul 2013 22:17:22 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: References: Message-ID: <60816F5B-68FA-4111-AC4E-AFE9FF8C3493@delong.com> >> What differences between ISPs and end-sites do you think are unfair. > > Votes, for one thing. There is no difference in voting rights for ISPs vs. end users. The only difference is in fees. ISP fees include membership and voting privileges in their base fees. For end users, membership is a separate fee, but once an end user pays their membership fee, they have the same voting rights as an ISP. The only difference is that ISPs don't have the option of opting out of voting rights. Owen From bill at herrin.us Sat Jul 13 12:37:02 2013 From: bill at herrin.us (William Herrin) Date: Sat, 13 Jul 2013 12:37:02 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: <60816F5B-68FA-4111-AC4E-AFE9FF8C3493@delong.com> References: <60816F5B-68FA-4111-AC4E-AFE9FF8C3493@delong.com> Message-ID: On Sat, Jul 13, 2013 at 1:17 AM, Owen DeLong wrote: >>> What differences between ISPs and end-sites do you think are unfair. >> Votes, for one thing. > The only difference is that ISPs don't have the option of opting out of voting rights. That's a huge difference. It means there's no practical chance of forming a coalition of voting end-users with end-user concerns. It guarantees the power stays with the service provider users. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sat Jul 13 12:52:15 2013 From: bill at herrin.us (William Herrin) Date: Sat, 13 Jul 2013 12:52:15 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51E0D19E.90209@umn.edu> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <5B9E90747FA2974D91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com> <51DF46C3.9020900@umn.edu> <51E0D19E.90209@umn.edu> Message-ID: On Sat, Jul 13, 2013 at 12:03 AM, David Farmer wrote: > I believe some form of conservation is applicable for all "number > resources", even ASNs. Hi David, I don't agree. I'm not the only one. And prior documents on the subject don't extend the concept beyond addresses. > I've provided what I think is a plausible situation where conservation > applied to ASNs could be beneficial. Can you provide a plausible situation > where conservation applied to ASNs could be harmful? Of course. It's harmful during every single ASN assignment. And not just theoretically. Preparing documentation which justifies an ASN assignment is not free. Processing the request and its documentation is not free either. Without a conservation concern, ASN requests are pro-forma. ARIN can streamlining the process: fast and cheap. > A Hypothetical; Is it in the interest of Internet for a bankruptcy trustee > to sell IPv4 addresses to a snow shoe spammer? How is something like this > prevented without a concept of conservation for IPv4? Registration. Conservation doesn't prevent the snow shoe spammer -- his use is technically justified the same way the IP-per-SSL-cert is justified. But he's rather motivated to remain anonymous. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sat Jul 13 17:21:56 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 13 Jul 2013 16:21:56 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51DB3076.5080304@arin.net> References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: On 7/8/13, ARIN wrote: > Draft Policy ARIN-2013-4 > RIR Principles I continue to have some objection to this draft, because it is still a statement of supposed principles, not policy. Per PDP 3.2 "proposals to change policy must address a clearly defined, existing or potential problem with number resource policy in the region." The purpose of ARIN policy is to define policy, not goals. The number resource policy manual is not the ARIN charter. PDP section 4 already defines principles of ARIN policy. So there does not appear to be anything to accomplish by the draft. "For example, Conservation often requires greater consideration in IPv4 address distribution due to the limited size of the address space, Routability has a higher weight for the massive IPv6 address space, and AS numbers place the highest value on Registration because they come from a moderately sized pool and are not subject to aggregation." This is no good.... we essentially have here a policy statement that ARIN should apply good judgement and consideration when using policy. Since they are supposed to do that anyways, the statement is redundant. We dont' need a policy statement say "Care must be taken to ensure balance with these conflicting goals " Care must be taken to ensure fairness and technical soundness given any conflicting policy.... The policy itself should be introducing conflicting circumstances: It's the policy's job to get updated to resolve conflicts of that nature. Policy should provide clear implementable guidelines, not vague assertions that "you need to be careful, read the author's mind, and do whatever that person would want....". -- -JH From owen at delong.com Sat Jul 13 19:08:01 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 13 Jul 2013 18:38:01 -0430 Subject: [arin-ppml] Draft Policy ARIN-2013-4: Fair Distribution In-Reply-To: References: <60816F5B-68FA-4111-AC4E-AFE9FF8C3493@delong.com> Message-ID: <185889C7-288B-4F0E-A297-E521A6B8D1C7@delong.com> I disagree. I don't think that history and policy reflect any such thing. While I agree it would be difficult to develop a voting block of end-user organizations as a force in ARIN elections, I don't for one second believe that it would be all that easy to develop a voting block of ISP organizations either. There is sufficient diversity of interests, concerns, focus, etc. in the ARIN membership, even while most of them are ISPs, that I don't see a meaningful voting block as a likely outcome. Further, since that only influences the content of the board and the AC, but has no other effect on the PDP, short of the board abandoning the principles for the PDP outlined in the bylaws and charter, I don't believe end-users are short changed when it comes to influencing policy. It would be very hard for me to look at existing policy and claim that it is skewed in favor of ISPs over end-user organizations. If anything, though I don't agree, I think one could make some case that it is skewed in the other direction. Owen On Jul 13, 2013, at 12:07 PM, William Herrin wrote: > On Sat, Jul 13, 2013 at 1:17 AM, Owen DeLong wrote: >>>> What differences between ISPs and end-sites do you think are unfair. >>> Votes, for one thing. > >> The only difference is that ISPs don't have the option of opting out of voting rights. > > That's a huge difference. It means there's no practical chance of > forming a coalition of voting end-users with end-user concerns. It > guarantees the power stays with the service provider users. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From gary.buhrmaster at gmail.com Sat Jul 13 19:11:59 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 13 Jul 2013 23:11:59 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <51DF46C3.9020900@umn.edu> Message-ID: On Fri, Jul 12, 2013 at 3:49 PM, Steven Ryerse wrote: > I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Obligatory xkcd ref: http://xkcd.com/865/ Gary From SRyerse at eclipse-networks.com Mon Jul 15 12:02:28 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 15 Jul 2013 16:02:28 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><5B9E90747FA2974D 91A54FCFA1B8AD1201368E202C@ENI-MAIL.eclipse-networks.com>, <51DF46C3.9020900@umn.edu> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> Note that I did say "right sized allocations" and have said multiple times that it is fine to match allocations with the size of the organization and/or the size of the organization's current network. I also have stated that we need to be good technical stewards and I think most folks here agree with that. I do not think a small organization like ours for example should ever get the technical equivalent of a /8 or even close to it. I do strongly think that every organization should be able to get a right sized allocation if they are going to use it as that grows the Internet - which in case folks forget is ARIN's mission. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] Sent: Friday, July 12, 2013 12:18 PM To: Steven Ryerse; David Farmer Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore. To be clear, IP Address schemes can only be updated so far. As far as I can tell IPv4 address schemes have never extended beyond the initial 32 bits they started off with, and IPv6 also will not change from a 128 bit address length. Granted, CIDR was introduced to IPv4 to extend the timeline for exhaust of IPv4 address resources, but this is exceptional, and not the rule (certainly for the future). And the cost you mention is not a negligible one. Think of the amount of time and energy that has already gone into IPv6 only to approach 2% of global IP traffic on IPv6. I believe it is in the community's best interest to conserve the word conservation in some form. As David said, the conservation of IPv6 resources is going to be much different than conservation of IPv4 resources. By the way, for those not following, there is a push from many member nations of the ITU and others in the international community to redistribute the governance of the internet in their interests. Do not be surprised if the nations gain the ability to allocate IP Address resources to the entities within their borders. In that world, IPv6 exhaust is only a short matter of time. If we can at least embed the concept of conservation of IPv6 resources now in some way, the global community will thank us a generation or two from now. mw On July 12, 2013 at 08:50 AM, "Steven Ryerse" wrote: > I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all - we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them. > Bill is right that the word conserve needs to be removed. > Sent from my iPhone > On Jul 11, 2013, at 7:59 PM, "David Farmer" wrote: > > I really don't understand this debate on Conservation. :{ > > > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > > > > Then others are not willing to concede that anything changes with IPv4 run-out. > > > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... > > > > So how do we move forward? I suggest; > > > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. > > > > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. > > > > 3. Are there other concepts, principles, or goals that were missing? > > I suggested earlier that there were additional principles we should > > be looking at. An candidates has come up in the conversation today > > that I would like to propose; > > > > 0.2 Fair Distribution > > > > The principle of Fair Distribution is the precept that the > > fundamental purpose of Internet number resources management is to > > distributed unique number resources in a fair and impartial manner > > to entities building and operating networks, for benefit of all > > Internet users equally, and thereby facilitating the growth and > > sustainability of the Internet. > > > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" > > > > Thanks > > -- > > ================================================ > > David Farmer Email: farmer at umn.edu > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 1-612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > ================================================ > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From David.Huberman at microsoft.com Mon Jul 15 12:34:07 2013 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 15 Jul 2013 16:34:07 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy Message-ID: <69a24076fa5245f09272880a662a585b@BN1PR03MB250.namprd03.prod.outlook.com> Hello, For 15 years, ARIN policy (derived from RFC2050) has promoted a dichotomy between provider networks and enterprise networks. I submit that the dichotomy between enterprises and providers is unbalanced, technically unjustified, and represents poor stewardship. I believe ARIN Policy should remove the barriers for provider networks who wish to begin numbering their network with space from the Registry. Under today's Policy framework, it is very easy to get an initial assignment of IPv4 addresses from the Registry if you are a multi-homed enterprise network. Qualifying for a /24 is as simple as having a need to use 64 IPv4 addresses right away, and projecting a need for at least 128 IPv4 addresses within one year. This Policy is, in this writer's opinion, very good. Under today's Policy framework, it is not very easy, however, to get an initial allocation of IPv4 addresses from the Registry if you are a multi-homed provider network. Qualifying for the minimum allocation size of a /22 requires the network to already be utilizing a /23 equivalent from other providers or peers, and be willing and able to commit to ARIN to renumbering out of that space before being eligible for an additional allocation. Normally, I would submit a Draft Policy Proposal to offer a sound policy solution. Watching PPML over the last 10 years, however, has me shying away from a proposal because I sense there are too many who are against any changes to the IPv4 policy framework. I am, therefore, posting this message in hopes of taking the temperature of the policy community. I think a potential policy change is relevant at such a late date because the math clearly shows that the largest networks will be the ones who will be first unable to receive meaningful additional IPv4 address blocks from ARIN. The smallest of networks should be able to receive allocations and assignments from ARIN long after the large networks have exhausted. I think, therefore, that a fix to what I believe is an unfair policy would be relevant for a few years going forward. What do you think? With regards, David [cid:image003.jpg at 01CE813E.732C4680] DAVID R Huberman Senior Program Manager Microsoft GFS 425-777-0259 (w) david.huberman at microsoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1819 bytes Desc: image003.jpg URL: From ikiris at gmail.com Mon Jul 15 15:00:47 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 15 Jul 2013 14:00:47 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <51DF46C3.9020900@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> Message-ID: Exactly how is this "right sized allocation" based on network size different than needs basis allocation? -Blake On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse < SRyerse at eclipse-networks.com> wrote: > Note that I did say "right sized allocations" and have said multiple times > that it is fine to match allocations with the size of the organization > and/or the size of the organization's current network. I also have stated > that we need to be good technical stewards and I think most folks here > agree with that. I do not think a small organization like ours for example > should ever get the technical equivalent of a /8 or even close to it. I do > strongly think that every organization should be able to get a right sized > allocation if they are going to use it as that grows the Internet - which > in case folks forget is ARIN's mission. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] > Sent: Friday, July 12, 2013 12:18 PM > To: Steven Ryerse; David Farmer > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > In that case, I would like to request a /8 of IPv6 space. That seems > right to me since conservation isn't a concern anymore. > > To be clear, IP Address schemes can only be updated so far. As far as I > can tell IPv4 address schemes have never extended beyond the initial 32 > bits they started off with, and IPv6 also will not change from a 128 bit > address length. Granted, CIDR was introduced to IPv4 to extend the > timeline for exhaust of IPv4 address resources, but this is exceptional, > and not the rule (certainly for the future). > > And the cost you mention is not a negligible one. Think of the amount of > time and energy that has already gone into IPv6 only to approach 2% of > global IP traffic on IPv6. I believe it is in the community's best > interest to conserve the word conservation in some form. As David said, > the conservation of IPv6 resources is going to be much different than > conservation of IPv4 resources. > > By the way, for those not following, there is a push from many member > nations of the ITU and others in the international community to > redistribute the governance of the internet in their interests. Do not be > surprised if the nations gain the ability to allocate IP Address resources > to the entities within their borders. In that world, IPv6 exhaust is only > a short matter of time. If we can at least embed the concept of > conservation of IPv6 resources now in some way, the global community will > thank us a generation or two from now. > > mw > > On July 12, 2013 at 08:50 AM, "Steven Ryerse" < > SRyerse at eclipse-networks.com> wrote: > > > I disagree. Unlike say land which they aren't making more of, address > schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll > switch to IPv8 or whatever (albeit at a cost) or something better than IP. > Thus we don't need to conserve at all - we just need to do right sized > allocations so we don't have to pay the additional cost to switch sooner > than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow > be conserved for a rainy day if there are folks that want to use them. > > > > Bill is right that the word conserve needs to be removed. > > > Sent from my iPhone > > > On Jul 11, 2013, at 7:59 PM, "David Farmer" wrote: > > > > I really don't understand this debate on Conservation. :{ > > > > > > There are some that seem to be claim that conservation is irrelevant > with IPv4 free pool run-out. > > > > > > I say so what! We still have IPv6 and ASNs to worry about, and while > both resource pools are GARGANTUAN by comparison, they are not infinite. > Therefore some concept of conservation remains necessary, obviously not > the same concept that we have had in IPv4 for the last 20 years or so. > But, completely eliminating conservation as a concept, principle, or goal, > of how we manage Internet number resources, seems like the proverbial > "throwing the baby out with the bath water." > > > > > > Then others are not willing to concede that anything changes with IPv4 > run-out. > > > > > > I'll can say I really hope something changes, the focus on > conservation that became necessary in the late '90s for IPv4, has nearly > lead to the abandonment of other principles like the end-to-end model, open > availability of resources (anyone building a network should be able to get > unique addresses), etc... > > > > > > So how do we move forward? I suggest; > > > > > > 1. Can everyone concede that going forward, conservation is much less > important, but that the need for some concept of conservation doesn't > completely go away either. > > > > > > 2. Lets focus the conversation on other issues for a while, let this > cool down a little, then come back to it after we've cooled down and maybe > have resolved some of the other issues. > > > > > > 3. Are there other concepts, principles, or goals that were missing? > > > I suggested earlier that there were additional principles we should > > > be looking at. An candidates has come up in the conversation today > > > that I would like to propose; > > > > > > 0.2 Fair Distribution > > > > > > The principle of Fair Distribution is the precept that the > > > fundamental purpose of Internet number resources management is to > > > distributed unique number resources in a fair and impartial manner > > > to entities building and operating networks, for benefit of all > > > Internet users equally, and thereby facilitating the growth and > > > sustainability of the Internet. > > > > > > I'd make this #2 behind Registration, and I'd suggest Conservation > could follow and ties into this principle through the concepts of > "fairness" and "sustainability" > > > > > > Thanks > > > -- > > > ================================================ > > > David Farmer Email: farmer at umn.edu > > > Office of Information Technology > > > University of Minnesota > > > 2218 University Ave SE Phone: 1-612-626-0815 > > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > > ================================================ > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Mon Jul 15 16:23:43 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 15 Jul 2013 20:23:43 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><51DF46C3.9020900@umn.edu> <5B9E90747FA29 74D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> If you are publicly traded and your company?s revenues are public then the size of the company is available to all. This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large block size. The other info that could be used is how much resource does an org have now. If they have a /8 they might really have use for another /8. If they have a /22 they might really have use for another /22. Obviously the org with a /22 isn?t likely to have use for a /8. Orgs with multiple allocations already can add them together including legacy blocks. An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 . The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle. I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required. In this way the blocks allocated are right sized for the size of the org requesting the allocation. There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Monday, July 15, 2013 3:01 PM To: Steven Ryerse Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Exactly how is this "right sized allocation" based on network size different than needs basis allocation? -Blake On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse > wrote: Note that I did say "right sized allocations" and have said multiple times that it is fine to match allocations with the size of the organization and/or the size of the organization's current network. I also have stated that we need to be good technical stewards and I think most folks here agree with that. I do not think a small organization like ours for example should ever get the technical equivalent of a /8 or even close to it. I do strongly think that every organization should be able to get a right sized allocation if they are going to use it as that grows the Internet - which in case folks forget is ARIN's mission. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] Sent: Friday, July 12, 2013 12:18 PM To: Steven Ryerse; David Farmer Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore. To be clear, IP Address schemes can only be updated so far. As far as I can tell IPv4 address schemes have never extended beyond the initial 32 bits they started off with, and IPv6 also will not change from a 128 bit address length. Granted, CIDR was introduced to IPv4 to extend the timeline for exhaust of IPv4 address resources, but this is exceptional, and not the rule (certainly for the future). And the cost you mention is not a negligible one. Think of the amount of time and energy that has already gone into IPv6 only to approach 2% of global IP traffic on IPv6. I believe it is in the community's best interest to conserve the word conservation in some form. As David said, the conservation of IPv6 resources is going to be much different than conservation of IPv4 resources. By the way, for those not following, there is a push from many member nations of the ITU and others in the international community to redistribute the governance of the internet in their interests. Do not be surprised if the nations gain the ability to allocate IP Address resources to the entities within their borders. In that world, IPv6 exhaust is only a short matter of time. If we can at least embed the concept of conservation of IPv6 resources now in some way, the global community will thank us a generation or two from now. mw On July 12, 2013 at 08:50 AM, "Steven Ryerse" > wrote: > I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all - we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them. > Bill is right that the word conserve needs to be removed. > Sent from my iPhone > On Jul 11, 2013, at 7:59 PM, "David Farmer" > wrote: > > I really don't understand this debate on Conservation. :{ > > > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > > > > Then others are not willing to concede that anything changes with IPv4 run-out. > > > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... > > > > So how do we move forward? I suggest; > > > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. > > > > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. > > > > 3. Are there other concepts, principles, or goals that were missing? > > I suggested earlier that there were additional principles we should > > be looking at. An candidates has come up in the conversation today > > that I would like to propose; > > > > 0.2 Fair Distribution > > > > The principle of Fair Distribution is the precept that the > > fundamental purpose of Internet number resources management is to > > distributed unique number resources in a fair and impartial manner > > to entities building and operating networks, for benefit of all > > Internet users equally, and thereby facilitating the growth and > > sustainability of the Internet. > > > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" > > > > Thanks > > -- > > ================================================ > > David Farmer Email: farmer at umn.edu > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 1-612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > ================================================ > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From cgrundemann at gmail.com Mon Jul 15 17:05:28 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 15 Jul 2013 15:05:28 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <51DF46C3.9020900@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> Message-ID: On Mon, Jul 15, 2013 at 2:23 PM, Steven Ryerse wrote: > If you are publicly traded and your company?s revenues are public then > the size of the company is available to all. This could be used to make > sure only a large organization who might actually have use for it can get a > /8 or other large > I can imagine many organizations that make lots of money but have very small networks, and many other organizations that make little to no money but have large networks. In other words, I don't see size of revenue as a good proxy for size of network. The same is generally true for number of employees, and basically every stat other than "how big is the network you operate and how fast is it growing?" That may effect the other metrics but I don't see a conclusive, reliable, direct, and proportional link between any of them. > block size. The other info that could be used is how much resource does > an org have now. If they have a /8 they might really have use for another > /8. If they have a /22 they might really have use for another /22. > Obviously the org with a /22 isn?t likely to have use for a /8. Orgs with > multiple allocations already can add them together including legacy > blocks. An org that has no allocation or one up to a /22 allocation should > be able to qualify for the currently defined minimum sized block which I > believe is currently a /22 . The rare case where an org with a very small > or no current allocation has use for a very large block can be handled as > an exception with more proof required that the block they are requesting ? > I?m thinking this would require a manager at ARIN to handle. I?m guessing > it is rare that an org needs to add more than double what they already have > allocated and those can be special cases handled as exceptions with > additional proof required. In this way the blocks allocated are right > sized for the size of the org requesting the allocation. There are some > smart folks in this community who might be able to tweak this idea and make > it better, especially for larger allocations. > A lot of this sounds reasonable, it all also sounds like possible tweaks to the manner in which need is assessed at ARIN. I don't see anything here that is inherently or necessarily out of line with the principle of conservation. What you are describing here are implementation details of one of the principles included in this draft policy from what I can tell. Cheers, ~Chris > **** > > ** ** > > *Steven L Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 - Cell* > > *770.399.9099 - Office* > > *770.392-0076 - Fax* > > ** ** > > [image: Description: Description: Description: Eclipse Networks > Logo_small.png]? Eclipse Networks, Inc.**** > > Conquering Complex Networks?**** > > ** ** > > *From:* Blake Dunlap [mailto:ikiris at gmail.com] > *Sent:* Monday, July 15, 2013 3:01 PM > *To:* Steven Ryerse > *Cc:* Matthew Wilder; David Farmer; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - > revised**** > > ** ** > > Exactly how is this "right sized allocation" based on network size > different than needs basis allocation?**** > > -Blake**** > > ** ** > > On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse < > SRyerse at eclipse-networks.com> wrote:**** > > Note that I did say "right sized allocations" and have said multiple times > that it is fine to match allocations with the size of the organization > and/or the size of the organization's current network. I also have stated > that we need to be good technical stewards and I think most folks here > agree with that. I do not think a small organization like ours for example > should ever get the technical equivalent of a /8 or even close to it. I do > strongly think that every organization should be able to get a right sized > allocation if they are going to use it as that grows the Internet - which > in case folks forget is ARIN's mission.**** > > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message-----**** > > From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] > Sent: Friday, July 12, 2013 12:18 PM > To: Steven Ryerse; David Farmer > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > In that case, I would like to request a /8 of IPv6 space. That seems > right to me since conservation isn't a concern anymore. > > To be clear, IP Address schemes can only be updated so far. As far as I > can tell IPv4 address schemes have never extended beyond the initial 32 > bits they started off with, and IPv6 also will not change from a 128 bit > address length. Granted, CIDR was introduced to IPv4 to extend the > timeline for exhaust of IPv4 address resources, but this is exceptional, > and not the rule (certainly for the future). > > And the cost you mention is not a negligible one. Think of the amount of > time and energy that has already gone into IPv6 only to approach 2% of > global IP traffic on IPv6. I believe it is in the community's best > interest to conserve the word conservation in some form. As David said, > the conservation of IPv6 resources is going to be much different than > conservation of IPv4 resources. > > By the way, for those not following, there is a push from many member > nations of the ITU and others in the international community to > redistribute the governance of the internet in their interests. Do not be > surprised if the nations gain the ability to allocate IP Address resources > to the entities within their borders. In that world, IPv6 exhaust is only > a short matter of time. If we can at least embed the concept of > conservation of IPv6 resources now in some way, the global community will > thank us a generation or two from now. > > mw > > On July 12, 2013 at 08:50 AM, "Steven Ryerse" < > SRyerse at eclipse-networks.com> wrote: > > > I disagree. Unlike say land which they aren't making more of, address > schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll > switch to IPv8 or whatever (albeit at a cost) or something better than IP. > Thus we don't need to conserve at all - we just need to do right sized > allocations so we don't have to pay the additional cost to switch sooner > than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow > be conserved for a rainy day if there are folks that want to use them. > > > > Bill is right that the word conserve needs to be removed. > > > Sent from my iPhone > > > On Jul 11, 2013, at 7:59 PM, "David Farmer" wrote: > > > > I really don't understand this debate on Conservation. :{ > > > > > > There are some that seem to be claim that conservation is irrelevant > with IPv4 free pool run-out. > > > > > > I say so what! We still have IPv6 and ASNs to worry about, and while > both resource pools are GARGANTUAN by comparison, they are not infinite. > Therefore some concept of conservation remains necessary, obviously not > the same concept that we have had in IPv4 for the last 20 years or so. > But, completely eliminating conservation as a concept, principle, or goal, > of how we manage Internet number resources, seems like the proverbial > "throwing the baby out with the bath water." > > > > > > Then others are not willing to concede that anything changes with IPv4 > run-out. > > > > > > I'll can say I really hope something changes, the focus on > conservation that became necessary in the late '90s for IPv4, has nearly > lead to the abandonment of other principles like the end-to-end model, open > availability of resources (anyone building a network should be able to get > unique addresses), etc... > > > > > > So how do we move forward? I suggest; > > > > > > 1. Can everyone concede that going forward, conservation is much less > important, but that the need for some concept of conservation doesn't > completely go away either. > > > > > > 2. Lets focus the conversation on other issues for a while, let this > cool down a little, then come back to it after we've cooled down and maybe > have resolved some of the other issues. > > > > > > 3. Are there other concepts, principles, or goals that were missing? > > > I suggested earlier that there were additional principles we should > > > be looking at. An candidates has come up in the conversation today > > > that I would like to propose; > > > > > > 0.2 Fair Distribution > > > > > > The principle of Fair Distribution is the precept that the > > > fundamental purpose of Internet number resources management is to > > > distributed unique number resources in a fair and impartial manner > > > to entities building and operating networks, for benefit of all > > > Internet users equally, and thereby facilitating the growth and > > > sustainability of the Internet. > > > > > > I'd make this #2 behind Registration, and I'd suggest Conservation > could follow and ties into this principle through the concepts of > "fairness" and "sustainability" > > > > > > Thanks > > > -- > > > ================================================ > > > David Farmer Email: farmer at umn.edu > > > Office of Information Technology > > > University of Minnesota > > > 2218 University Ave SE Phone: 1-612-626-0815 > > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > > ================================================ > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues.**** > > ** ** > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann http://chrisgrundemann.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: not available URL: From farmer at umn.edu Mon Jul 15 17:05:48 2013 From: farmer at umn.edu (David Farmer) Date: Mon, 15 Jul 2013 16:05:48 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><51DF46C3.9020900@umn.edu> <5B9E90747FA29 74D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> Message-ID: <51E4642C.8090806@umn.edu> Steven, In your "right sized allocations" vision for policy is it necessary for a large company with a /8 to demonstrate that they are using the current /8 they have before they can get another one? How long after they get there new /8 can they ask for another one, 1 day, 1 month, 1 year, 2 years..? Thanks On 7/15/13 15:23 , Steven Ryerse wrote: > If you are publicly traded and your company?s revenues are public then > the size of the company is available to all. This could be used to make > sure only a large organization who might actually have use for it can > get a /8 or other large block size. The other info that could be used > is how much resource does an org have now. If they have a /8 they might > really have use for another /8. If they have a /22 they might really > have use for another /22. Obviously the org with a /22 isn?t likely to > have use for a /8. Orgs with multiple allocations already can add them > together including legacy blocks. An org that has no allocation or one > up to a /22 allocation should be able to qualify for the currently > defined minimum sized block which I believe is currently a /22 . The > rare case where an org with a very small or no current allocation has > use for a very large block can be handled as an exception with more > proof required that the block they are requesting ? I?m thinking this > would require a manager at ARIN to handle. I?m guessing it is rare that > an org needs to add more than double what they already have allocated > and those can be special cases handled as exceptions with additional > proof required. In this way the blocks allocated are right sized for > the size of the org requesting the allocation. There are some smart > folks in this community who might be able to tweak this idea and make it > better, especially for larger allocations. > > /Steven L Ryerse/ > > /President/ > > /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ > > /770.656.1460 - Cell/ > > /770.399.9099 - Office/ > > /770.392-0076 - Fax/ > > Description: Description: Description: Eclipse Networks > Logo_small.png?Eclipse Networks, Inc. > > ^ Conquering Complex Networks ^? ^ > > *From:*Blake Dunlap [mailto:ikiris at gmail.com] > *Sent:* Monday, July 15, 2013 3:01 PM > *To:* Steven Ryerse > *Cc:* Matthew Wilder; David Farmer; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - > revised > > Exactly how is this "right sized allocation" based on network size > different than needs basis allocation? > > -Blake > > On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse > > wrote: > > Note that I did say "right sized allocations" and have said multiple > times that it is fine to match allocations with the size of the > organization and/or the size of the organization's current network. I > also have stated that we need to be good technical stewards and I think > most folks here agree with that. I do not think a small organization > like ours for example should ever get the technical equivalent of a /8 > or even close to it. I do strongly think that every organization should > be able to get a right sized allocation if they are going to use it as > that grows the Internet - which in case folks forget is ARIN's mission. > > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From cgrundemann at gmail.com Mon Jul 15 17:15:22 2013 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 15 Jul 2013 15:15:22 -0600 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <69a24076fa5245f09272880a662a585b@BN1PR03MB250.namprd03.prod.outlook.com> References: <69a24076fa5245f09272880a662a585b@BN1PR03MB250.namprd03.prod.outlook.com> Message-ID: On Mon, Jul 15, 2013 at 10:34 AM, David Huberman < David.Huberman at microsoft.com> wrote: > Hello,**** > > ** ** > > For 15 years, ARIN policy (derived from RFC2050) has promoted a dichotomy > between provider networks and enterprise networks. I submit that the > dichotomy between enterprises and providers is unbalanced, technically > unjustified, and represents poor stewardship. I believe ARIN Policy should > remove the barriers for provider networks who wish to begin numbering their > network with space from the Registry.**** > > ** ** > > Under today?s Policy framework, it is very easy to get an initial > assignment of IPv4 addresses from the Registry if you are a multi-homed > enterprise network. Qualifying for a /24 is as simple as having a need to > use 64 IPv4 addresses right away, and projecting a need for at least 128 > IPv4 addresses within one year. This Policy is, in this writer?s opinion, > very good.**** > > ** ** > > Under today?s Policy framework, it is not very easy, however, to get an > initial allocation of IPv4 addresses from the Registry if you are a > multi-homed provider network. Qualifying for the minimum allocation size of > a /22 requires the network to already be utilizing a /23 equivalent from > other providers or peers, and be willing and able to commit to ARIN to > renumbering out of that space before being eligible for an additional > allocation.**** > > ** ** > > Normally, I would submit a Draft Policy Proposal to offer a sound policy > solution. Watching PPML over the last 10 years, however, has me shying > away from a proposal because I sense there are too many who are against any > changes to the IPv4 policy framework. I am, therefore, posting this > message in hopes of taking the temperature of the policy community. **** > > ** ** > > I think a potential policy change is relevant at such a late date because > the math clearly shows that the largest networks will be the ones who will > be first unable to receive meaningful additional IPv4 address blocks from > ARIN. The smallest of networks should be able to receive allocations and > assignments from ARIN long after the large networks have exhausted. I > think, therefore, that a fix to what I believe is an unfair policy would be > relevant for a few years going forward.**** > > ** ** > > What do you think? > I think that's right in line with what is being discussed wrt ARIN-2013-5 "LIR/ISP and End-user Definitions". Have you followed that discussion? Sounds like you may want to. Cheers, ~Chris > **** > > ** ** > > With regards,**** > > David**** > > ** ** > > **** > > *DAVID R Huberman*** > > *Senior Program Manager *** > > Microsoft GFS**** > > 425-777-0259 (w)**** > > david.huberman at microsoft.com**** > > ** ** > > ** ** > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann http://chrisgrundemann.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1819 bytes Desc: not available URL: From SRyerse at eclipse-networks.com Mon Jul 15 17:56:45 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 15 Jul 2013 21:56:45 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0 $0c13a640$@tndh.net><51DF46C3.9020900@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.eclipse-networks.com> Chris, I would use their existing network size first and then company size if available to help determine exceptions. The big guys with a big request like T-Mobile who got around three quarters of a /8 awhile back are probably going to be handled by ARIN management anyway. If for example AT&T or Verizon decided they needed a /8 today I suspect that ARIN would help them get what they say they need. I realize this subject is political and somewhat controversial based on the past discussions about T-Mobile and Microsoft obtaining large blocks, and I don?t wish to rehash that here - but it is debatable whether ARIN in real life would make them prove they need it with a zillion ARP logs and whatever. And I know John would say publicly ARIN would make them prove it and I don?t have a problem empowering John with the authority to determine what a big guy needs to provide to prove it. So let the big guys get big blocks and let the small guys get small blocks and make them all use their existing network size to help right size the request. I think ARIN managers are capable of handling the exceptions and I?m guessing there are probably not that many times a small existing network wants a big block. Lastly let an org that doesn?t like the size of their allocation have an appeal option to ARIN management and empower ARIN management to look to see if they think an exception is warranted. One of the definitions of Conserve is to Preserve. I know the definition in the proposal tries to better define what is meant by Conserve but we can?t preserve IPv4 and really for the same reasons we can?t preserve IPv6 forever. Better we be good technical stewards and have ARIN fulfill its mission to grow the Internet wherever it can and we all benefit. So I think William was on the money when he suggested removing the word Conservation. David asked: In your "right sized allocations" vision for policy is it necessary for a large company with a /8 to demonstrate that they are using the current /8 they have before they can get another one? How long after they get there new /8 can they ask for another one, 1 day, 1 month, 1 year, 2 years..? As I said above, in the real world with a real allocation request of a large block request, John is going to do his fiduciary duty and do what he thinks is best based on everything he knows. I?m sure he did ask T-Mobile if they needed a /8 or the three quarters of the /8 that they got. I?m sure they did respond with what he thought was a reasonable answer at that time. I doubt he asked to see oodles of ARP table reports or other physical evidence of need. (I could be wrong of course.) I doubt he made them calculate how long the allocation they requested would last per ARIN?s then current policy. (I could be wrong of course.) I think the answer to when should T-Mobile (or anyone else) get another large (or smaller) allocation is when they have actual use for it. Need based policies encourage fibbing (or outright lying) and I haven?t seen any allocations rescinded based on the org not using all of the allocation as fast as the org told ARIN they would actually use them. It is better to just have ARIN follow its mission and get allocations out in the real world where they can be used and not try to preserve them when we all know they can?t be preserved. Getting IP allocations out there worked great by Jon Postel to grow the Internet and we all have benefitted. Trying to find ways to not get allocations out there does the opposite and we all lose when that happens. We should follow Jon?s lead and get as many right sized allocations out there as we can so we all can continue to win. ? Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Chris Grundemann [mailto:cgrundemann at gmail.com] Sent: Monday, July 15, 2013 5:05 PM To: Steven Ryerse Cc: Blake Dunlap; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Mon, Jul 15, 2013 at 2:23 PM, Steven Ryerse > wrote: If you are publicly traded and your company?s revenues are public then the size of the company is available to all. This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large I can imagine many organizations that make lots of money but have very small networks, and many other organizations that make little to no money but have large networks. In other words, I don't see size of revenue as a good proxy for size of network. The same is generally true for number of employees, and basically every stat other than "how big is the network you operate and how fast is it growing?" That may effect the other metrics but I don't see a conclusive, reliable, direct, and proportional link between any of them. block size. The other info that could be used is how much resource does an org have now. If they have a /8 they might really have use for another /8. If they have a /22 they might really have use for another /22. Obviously the org with a /22 isn?t likely to have use for a /8. Orgs with multiple allocations already can add them together including legacy blocks. An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 . The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle. I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required. In this way the blocks allocated are right sized for the size of the org requesting the allocation. There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations. A lot of this sounds reasonable, it all also sounds like possible tweaks to the manner in which need is assessed at ARIN. I don't see anything here that is inherently or necessarily out of line with the principle of conservation. What you are describing here are implementation details of one of the principles included in this draft policy from what I can tell. Cheers, ~Chris Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Monday, July 15, 2013 3:01 PM To: Steven Ryerse Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Exactly how is this "right sized allocation" based on network size different than needs basis allocation? -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From SRyerse at eclipse-networks.com Mon Jul 15 18:07:29 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 15 Jul 2013 22:07:29 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0 $0c13a640$@tndh.net><51DF46C3.9020900@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MA IL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclipse-networks.com> One more thing. I think the ARIN Mission Statement was well crafted and does a very good job of providing us with the principles of how policies should be crafted. Why don?t we start there and build principles that follow the Mission Statement. Otherwise the Mission Statement should be changed to reflect a different mission. (I for one wouldn?t support a Mission Statement change.) Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Monday, July 15, 2013 5:57 PM To: Chris Grundemann Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Chris, I would use their existing network size first and then company size if available to help determine exceptions. The big guys with a big request like T-Mobile who got around three quarters of a /8 awhile back are probably going to be handled by ARIN management anyway. If for example AT&T or Verizon decided they needed a /8 today I suspect that ARIN would help them get what they say they need. I realize this subject is political and somewhat controversial based on the past discussions about T-Mobile and Microsoft obtaining large blocks, and I don?t wish to rehash that here - but it is debatable whether ARIN in real life would make them prove they need it with a zillion ARP logs and whatever. And I know John would say publicly ARIN would make them prove it and I don?t have a problem empowering John with the authority to determine what a big guy needs to provide to prove it. So let the big guys get big blocks and let the small guys get small blocks and make them all use their existing network size to help right size the request. I think ARIN managers are capable of handling the exceptions and I?m guessing there are probably not that many times a small existing network wants a big block. Lastly let an org that doesn?t like the size of their allocation have an appeal option to ARIN management and empower ARIN management to look to see if they think an exception is warranted. One of the definitions of Conserve is to Preserve. I know the definition in the proposal tries to better define what is meant by Conserve but we can?t preserve IPv4 and really for the same reasons we can?t preserve IPv6 forever. Better we be good technical stewards and have ARIN fulfill its mission to grow the Internet wherever it can and we all benefit. So I think William was on the money when he suggested removing the word Conservation. David asked: In your "right sized allocations" vision for policy is it necessary for a large company with a /8 to demonstrate that they are using the current /8 they have before they can get another one? How long after they get there new /8 can they ask for another one, 1 day, 1 month, 1 year, 2 years..? As I said above, in the real world with a real allocation request of a large block request, John is going to do his fiduciary duty and do what he thinks is best based on everything he knows. I?m sure he did ask T-Mobile if they needed a /8 or the three quarters of the /8 that they got. I?m sure they did respond with what he thought was a reasonable answer at that time. I doubt he asked to see oodles of ARP table reports or other physical evidence of need. (I could be wrong of course.) I doubt he made them calculate how long the allocation they requested would last per ARIN?s then current policy. (I could be wrong of course.) I think the answer to when should T-Mobile (or anyone else) get another large (or smaller) allocation is when they have actual use for it. Need based policies encourage fibbing (or outright lying) and I haven?t seen any allocations rescinded based on the org not using all of the allocation as fast as the org told ARIN they would actually use them. It is better to just have ARIN follow its mission and get allocations out in the real world where they can be used and not try to preserve them when we all know they can?t be preserved. Getting IP allocations out there worked great by Jon Postel to grow the Internet and we all have benefitted. Trying to find ways to not get allocations out there does the opposite and we all lose when that happens. We should follow Jon?s lead and get as many right sized allocations out there as we can so we all can continue to win. ? Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Chris Grundemann [mailto:cgrundemann at gmail.com] Sent: Monday, July 15, 2013 5:05 PM To: Steven Ryerse Cc: Blake Dunlap; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Mon, Jul 15, 2013 at 2:23 PM, Steven Ryerse > wrote: If you are publicly traded and your company?s revenues are public then the size of the company is available to all. This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large I can imagine many organizations that make lots of money but have very small networks, and many other organizations that make little to no money but have large networks. In other words, I don't see size of revenue as a good proxy for size of network. The same is generally true for number of employees, and basically every stat other than "how big is the network you operate and how fast is it growing?" That may effect the other metrics but I don't see a conclusive, reliable, direct, and proportional link between any of them. block size. The other info that could be used is how much resource does an org have now. If they have a /8 they might really have use for another /8. If they have a /22 they might really have use for another /22. Obviously the org with a /22 isn?t likely to have use for a /8. Orgs with multiple allocations already can add them together including legacy blocks. An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 . The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle. I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required. In this way the blocks allocated are right sized for the size of the org requesting the allocation. There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations. A lot of this sounds reasonable, it all also sounds like possible tweaks to the manner in which need is assessed at ARIN. I don't see anything here that is inherently or necessarily out of line with the principle of conservation. What you are describing here are implementation details of one of the principles included in this draft policy from what I can tell. Cheers, ~Chris Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Monday, July 15, 2013 3:01 PM To: Steven Ryerse Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Exactly how is this "right sized allocation" based on network size different than needs basis allocation? -Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From Matthew.Wilder at telus.com Mon Jul 15 18:30:19 2013 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Mon, 15 Jul 2013 16:30:19 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0 $0c13a640$@tndh.net><51DF46C3.9020900@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MA IL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclipse-networks.com> Message-ID: Remember, though, that ARIN is not the same as the community. According to the mission statement, ARIN ?coordinates the development of policies by the community for the management of Internet Protocol number resources?? It is essential to differentiate ARIN and the community, given that ARIN does not develop policies. ARIN staff weighs in on policies through the Policy Development Process (PDP, viewable here: https://www.arin.net/policy/pdp.html) and ultimately implements the policy in their operational roles. In other words, the community ? and not ARIN ? is the originator of the principles on which policies are developed. As far as your comment on the use of the word conservation, I believe I now see your issue with the word. In your mind conservation means ?don?t give anything to anybody?. At the same time, I don?t think the word can reasonably be understood to have that meaning. It is obvious that ARIN continues to allocate and assign resources (and probably will do so until these resources exhaust). So while I understand the point you are getting at, I would posit that the word ?conservation? is as good as any in describing the intent to carefully and appropriately manage the allocation of resources. mw From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: July 15, 2013 03:07 PM To: Steven Ryerse; Chris Grundemann Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised One more thing.? I think the ARIN Mission Statement was well crafted and does a very good job of providing us with the principles of how policies should be crafted.? Why don?t we start there and build principles that follow the Mission Statement.? Otherwise the Mission Statement should be changed to reflect a different mission.? ?(I for one wouldn?t support a Mission Statement change.) Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Monday, July 15, 2013 5:57 PM To: Chris Grundemann Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Chris, I would use their existing network size first and then company size if available to help determine exceptions.? The big guys with a big request like T-Mobile who got around three quarters of a /8 awhile back are probably going to be handled by ARIN management anyway.? If for example AT&T or Verizon decided they needed a /8 today I suspect that ARIN would help them get what they say they need. I realize this subject is political and somewhat controversial based on the past discussions about T-Mobile and Microsoft obtaining large blocks, and I don?t wish to rehash that here - but it is debatable whether ARIN in real life would make them prove they need it with a zillion ARP logs and whatever.? And ?I know John would say publicly ARIN would make them prove it and I don?t have a problem empowering John with the authority to determine what a big guy needs to provide to prove it.? So let the big guys get big blocks and let the small guys get small blocks and make them all use their existing network size to help right size the request.? I think ARIN managers are capable of handling the exceptions and I?m guessing there are probably not that many times a small existing network wants a big block.? Lastly let an org that doesn?t like the size of their allocation have an appeal option to ARIN management and empower ARIN management to look to see if they think an exception is warranted.? One of the definitions of Conserve is to Preserve.? I know the definition in the proposal tries to better define what is meant by Conserve but we can?t preserve IPv4 and really for the same reasons we can?t preserve IPv6 forever.? Better we be good technical stewards and have ARIN fulfill its mission to grow the Internet wherever it can and we all benefit.? So I think William was on the money when he suggested removing the word Conservation.? David asked:? In your "right sized allocations" vision for policy is it necessary for a large company with a /8 to demonstrate that they are using the current /8 they have before they can get another one?? How long after they get there new /8 can they ask for another one, 1 day, 1 month, 1 year, 2 years..? As I said above, in the real world with a real allocation request of a large block request, John is going to do his fiduciary duty and do what he thinks is best based on everything he knows.? I?m sure he did ask T-Mobile if they needed a /8 or the three quarters of the /8 that they got.? I?m sure they did respond with what he thought was a reasonable answer at that time.? I doubt he asked to see oodles of ARP table reports or other physical evidence of need.? (I could be wrong of course.)? I doubt he made them calculate how long the allocation they requested would last per ARIN?s then current policy.? (I could be wrong of course.)? I think the answer to when should T-Mobile (or anyone else) get another large (or smaller) allocation is when they have actual use for it.? Need based policies encourage fibbing (or outright lying) and I haven?t seen any allocations rescinded based on the org not using all of the allocation as fast as the org told ARIN they would actually use them.? It is better to just have ARIN follow its mission and get allocations out in the real world where they can be used and not try to preserve them when we all know they can?t be preserved.? Getting IP allocations out there worked great by Jon Postel to grow the Internet and we all have benefitted.? Trying to find ways to not get allocations out there does the opposite and we all lose when that happens.? We should follow Jon?s lead and get as many right sized allocations out there as we can so we all can continue to win.? ? Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? From: Chris Grundemann [mailto:cgrundemann at gmail.com] Sent: Monday, July 15, 2013 5:05 PM To: Steven Ryerse Cc: Blake Dunlap; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Mon, Jul 15, 2013 at 2:23 PM, Steven Ryerse wrote: If you are publicly traded and your company?s revenues are public then the size of the company is available to all.? This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large I can imagine many organizations that make lots of money but have very small networks, and many other organizations that make little to no money but have large networks. In other words, I don't see size of revenue as a good proxy for size of network. The same is generally true for number of employees, and basically every stat other than "how big is the network you operate and how fast is it growing?" That may effect the other metrics but I don't see a conclusive, reliable, direct, and proportional link between any of them. ? block size.? The other info that could be used is how much resource does an org have now.? If they have a /8 they might really have use for another /8.? If they have a /22 they might really have use for another /22.? Obviously the org with a /22 isn?t likely to have use for a /8.? Orgs with multiple allocations already can add them together including legacy blocks.? An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 .? The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle.? I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required.? In this way the blocks allocated are right sized for the size of the org requesting the allocation.? There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations.? A lot of this sounds reasonable, it all also sounds like possible tweaks to the manner in which need is assessed at ARIN. I don't see anything here that is inherently or necessarily out of line with the principle of conservation. What you are describing here are implementation details of one of the principles included in this draft policy from what I can tell. Cheers, ~Chris ? ? Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? ? From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Monday, July 15, 2013 3:01 PM To: Steven Ryerse Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised ? Exactly how is this "right sized allocation" based on network size different than needs basis allocation? -Blake ? From SRyerse at eclipse-networks.com Mon Jul 15 18:53:51 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 15 Jul 2013 22:53:51 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <01f601ce7e73$04068cc0 $0c13a640$@tndh.net><51DF46C3.9020900@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MA IL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.eclip se-networks.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> So I infer from your comments that this community doesn't have to help create policies that align with ARIN's stated mission. Wow! So following that logic to the extreme then would it be OK for this community to create a policy that no more allocations of any kind will be made? I think not! So then is it OK for this community to create policies that's primary goal is to partially stop allocations? Using the exact same logic as I used above - I think not. I do think it is OK for this community to help create policies that right size allocations and I think that is covered in the Mission Statement. I humbly submit that ignorance of ARINs Mission Statement is the underlying problem why I think policy making in this community has gone off track. -----Original Message----- From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] Sent: Monday, July 15, 2013 6:30 PM To: Steven Ryerse; Chris Grundemann Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Remember, though, that ARIN is not the same as the community. According to the mission statement, ARIN ?coordinates the development of policies by the community for the management of Internet Protocol number resources?? It is essential to differentiate ARIN and the community, given that ARIN does not develop policies. ARIN staff weighs in on policies through the Policy Development Process (PDP, viewable here: https://www.arin.net/policy/pdp.html) and ultimately implements the policy in their operational roles. In other words, the community ? and not ARIN ? is the originator of the principles on which policies are developed. As far as your comment on the use of the word conservation, I believe I now see your issue with the word. In your mind conservation means ?don?t give anything to anybody?. At the same time, I don?t think the word can reasonably be understood to have that meaning. It is obvious that ARIN continues to allocate and assign resources (and probably will do so until these resources exhaust). So while I understand the point you are getting at, I would posit that the word ?conservation? is as good as any in describing the intent to carefully and appropriately manage the allocation of resources. mw From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: July 15, 2013 03:07 PM To: Steven Ryerse; Chris Grundemann Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised One more thing.? I think the ARIN Mission Statement was well crafted and does a very good job of providing us with the principles of how policies should be crafted.? Why don?t we start there and build principles that follow the Mission Statement.? Otherwise the Mission Statement should be changed to reflect a different mission.? ?(I for one wouldn?t support a Mission Statement change.) Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Monday, July 15, 2013 5:57 PM To: Chris Grundemann Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Chris, I would use their existing network size first and then company size if available to help determine exceptions.? The big guys with a big request like T-Mobile who got around three quarters of a /8 awhile back are probably going to be handled by ARIN management anyway.? If for example AT&T or Verizon decided they needed a /8 today I suspect that ARIN would help them get what they say they need. I realize this subject is political and somewhat controversial based on the past discussions about T-Mobile and Microsoft obtaining large blocks, and I don?t wish to rehash that here - but it is debatable whether ARIN in real life would make them prove they need it with a zillion ARP logs and whatever.? And ?I know John would say publicly ARIN would make them prove it and I don?t have a problem empowering John with the authority to determine what a big guy needs to provide to prove it.? So let the big guys get big blocks and let the small guys get small blocks and make them all use their existing network size to help right size the request.? I think ARIN managers are capable of handling the exceptions and I?m guessing there are probably not that many times a small existing network wants a big block.? Lastly let an org that doesn?t like the size of their allocation have an appeal option to ARIN management and empower ARIN management to look to see if they think an exception is warranted.? One of the definitions of Conserve is to Preserve.? I know the definition in the proposal tries to better define what is meant by Conserve but we can?t preserve IPv4 and really for the same reasons we can?t preserve IPv6 forever.? Better we be good technical stewards and have ARIN fulfill its mission to grow the Internet wherever it can and we all benefit.? So I think William was on the money when he suggested removing the word Conservation.? David asked:? In your "right sized allocations" vision for policy is it necessary for a large company with a /8 to demonstrate that they are using the current /8 they have before they can get another one?? How long after they get there new /8 can they ask for another one, 1 day, 1 month, 1 year, 2 years..? As I said above, in the real world with a real allocation request of a large block request, John is going to do his fiduciary duty and do what he thinks is best based on everything he knows.? I?m sure he did ask T-Mobile if they needed a /8 or the three quarters of the /8 that they got.? I?m sure they did respond with what he thought was a reasonable answer at that time.? I doubt he asked to see oodles of ARP table reports or other physical evidence of need.? (I could be wrong of course.)? I doubt he made them calculate how long the allocation they requested would last per ARIN?s then current policy.? (I could be wrong of course.)? I think the answer to when should T-Mobile (or anyone else) get another large (or smaller) allocation is when they have actual use for it.? Need based policies encourage fibbing (or outright lying) and I haven?t seen any allocations rescinded based on the org not using all of the allocation as fast as the org told ARIN they would actually use them.? It is better to just have ARIN follow its mission and get allocations out in the real world where they can be used and not try to preserve them when we all know they can?t be preserved.? Getting IP allocations out there worked great by Jon Postel to grow the Internet and we all have benefitted.? Trying to find ways to not get allocations out there does the opposite and we all lose when that happens.? We should follow Jon?s lead and get as many right sized allocations out there as we can so we all can continue to win.? ? Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? From: Chris Grundemann [mailto:cgrundemann at gmail.com] Sent: Monday, July 15, 2013 5:05 PM To: Steven Ryerse Cc: Blake Dunlap; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Mon, Jul 15, 2013 at 2:23 PM, Steven Ryerse wrote: If you are publicly traded and your company?s revenues are public then the size of the company is available to all.? This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large I can imagine many organizations that make lots of money but have very small networks, and many other organizations that make little to no money but have large networks. In other words, I don't see size of revenue as a good proxy for size of network. The same is generally true for number of employees, and basically every stat other than "how big is the network you operate and how fast is it growing?" That may effect the other metrics but I don't see a conclusive, reliable, direct, and proportional link between any of them. ? block size.? The other info that could be used is how much resource does an org have now.? If they have a /8 they might really have use for another /8.? If they have a /22 they might really have use for another /22.? Obviously the org with a /22 isn?t likely to have use for a /8.? Orgs with multiple allocations already can add them together including legacy blocks.? An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 .? The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle.? I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required.? In this way the blocks allocated are right sized for the size of the org requesting the allocation.? There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations.? A lot of this sounds reasonable, it all also sounds like possible tweaks to the manner in which need is assessed at ARIN. I don't see anything here that is inherently or necessarily out of line with the principle of conservation. What you are describing here are implementation details of one of the principles included in this draft policy from what I can tell. Cheers, ~Chris ? ? Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? ? From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Monday, July 15, 2013 3:01 PM To: Steven Ryerse Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised ? Exactly how is this "right sized allocation" based on network size different than needs basis allocation? -Blake ? From farmer at umn.edu Mon Jul 15 19:08:16 2013 From: farmer at umn.edu (David Farmer) Date: Mon, 15 Jul 2013 18:08:16 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0 $0c13a640$@tndh.net><51DF46C3.9020900@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MA IL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.eclip se-networks.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> Message-ID: <51E480E0.7070606@umn.edu> On 7/15/13 17:53 , Steven Ryerse wrote: > So I infer from your comments that this community doesn't have to help create policies that align with ARIN's stated mission. Wow! So following that logic to the extreme then would it be OK for this community to create a policy that no more allocations of any kind will be made? I think not! So then is it OK for this community to create policies that's primary goal is to partially stop allocations? Using the exact same logic as I used above - I think not. I do think it is OK for this community to help create policies that right size allocations and I think that is covered in the Mission Statement. > > I humbly submit that ignorance of ARINs Mission Statement is the underlying problem why I think policy making in this community has gone off track. No policies have to align with the mission statement, or if they are far enough out of line with the mission statement the Board wouldn't approve a policy. However, the mission statement isn't as clear cut as you seem to think it is. ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach. The above mission statement allow a wide variety of things, the interpretation of which of those are good or bad is mostly up to the community. And I don't see how any of the proposed Principles in ARIN-2013-4 conflict with the mission statement. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jschiller at google.com Mon Jul 15 21:37:29 2013 From: jschiller at google.com (Jason Schiller) Date: Mon, 15 Jul 2013 21:37:29 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: Jimmy, As Chris has pointed out... there are still a lot of documents that point to RFC2050 and reference stewardship principles, such as NRPM section 4.1.7 https://www.arin.net/policy/nrpm.html#four17 The problem is with recent updates, RFC-2050 lacks much of the stewardship principles that people tend to point to. This proposal is an attempt to collect these principles in one coherent place, and not loose the text when the original RFC2050 is deprecated. This is the only goal of this proposal. It is not intended to be policy, but rather is text that has guided policy development and it is hoped will be used to continue to guide policy development. It has been suggested by many that an RFC is not the right place to record these principles as they are not prescriptions that the IETF places on the RIRs. The PDP changes frequently, and it doesn't seem to have much community input. So that left placing these principles in the NRPM. A place that the community looks after and can easily change. It is possible, assuming there is community consensus on what the principles should be, that they could be moved out of the NRPM and placed in the ARIN bi-laws or some other place, but that may take changes out the hands of the community, and make it even more difficult to update.... I'm not sure that is a good feature. > "For example, Conservation often requires greater consideration in > IPv4 address distribution due to the limited size of the address > space, Routability has a higher weight for the massive IPv6 address > space, and AS numbers place the highest value on Registration because > they > come from a moderately sized pool and are not subject to aggregation." > > > This is no good.... we essentially have here a policy statement > that ARIN should apply good judgement and consideration when using > policy. No. We have a suggestion that the community should carefully balance these principles an use that to guide them in forming actual policy. __Jason On Sat, Jul 13, 2013 at 5:21 PM, Jimmy Hess wrote: > On 7/8/13, ARIN wrote: > > Draft Policy ARIN-2013-4 > > RIR Principles > > I continue to have some objection to this draft, because it is still > a statement of supposed principles, not policy. Per PDP 3.2 > "proposals to change policy must address a clearly defined, existing > or potential problem with number resource policy in the region." > > The purpose of ARIN policy is to define policy, not goals. The number > resource policy manual is not the ARIN charter. > > PDP section 4 already defines principles of ARIN policy. > > So there does not appear to be anything to accomplish by the draft. > > > "For example, Conservation often requires greater consideration in > IPv4 address distribution due to the limited size of the address > space, Routability has a higher weight for the massive IPv6 address > space, and AS numbers place the highest value on Registration because > they > come from a moderately sized pool and are not subject to aggregation." > > > This is no good.... we essentially have here a policy statement > that ARIN should apply good judgement and consideration when using > policy. > > Since they are supposed to do that anyways, the statement is redundant. > > We dont' need a policy statement say "Care must be taken to ensure > balance with these > conflicting goals " > > Care must be taken to ensure fairness and technical soundness given > any conflicting policy.... > > > The policy itself should be introducing conflicting circumstances: > It's the policy's job to get updated to resolve conflicts of that > nature. > > Policy should provide clear implementable guidelines, not vague > assertions that "you need to be careful, read the author's mind, and > do whatever that person would want....". > > -- > -JH > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 15 22:39:37 2013 From: jcurran at arin.net (John Curran) Date: Tue, 16 Jul 2013 02:39:37 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: <3E3142A7-7456-499E-B380-B098C19B8501@corp.arin.net> On Jul 15, 2013, at 9:37 PM, Jason Schiller wrote: > So that left placing these principles in the NRPM. A place that the > community looks after and can easily change. > > It is possible, assuming there is community consensus on what the > principles should be, that they could be moved out of the NRPM > and placed in the ARIN bi-laws or some other place, but that may > take changes out the hands of the community, and make it even > more difficult to update.... I'm not sure that is a good feature. If these truly are the foundational principals of the Internet Number Registry System, as expressed via the community-based development process, then one would expect that they would: - Not change very often - Be common across all of the regions - Eventually make it into some form of globally coordinated policy If there are simply principles that apply in the ARIN region, then the NRPM is a perfectly suitable place to locate them (just as are presently expressed in the beginning of NRPM section 4 and section 6.) Thanks! /John John Curran President and CEO ARIN From dave at temk.in Tue Jul 16 10:21:40 2013 From: dave at temk.in (David Temkin) Date: Tue, 16 Jul 2013 10:21:40 -0400 Subject: [arin-ppml] NANOG 59 - Important Schedule Notice & Call For Presentations. Please read! In-Reply-To: References: Message-ID: Reminder - submissions are due 30 days from today. The sooner the better, as it gives the Program Committee more time to help submitters refine their presentations for the NANOG audience. Regards, -Dave On Mon, Jun 17, 2013 at 3:33 PM, David Temkin wrote: > NANOG Community, > > I hope everyone enjoyed New Orleans as much as I did! It's truly one of > my favorite cities in the world. Fresh off a great meeting, we're already > starting to get ready for NANOG 59 in Phoenix. If you have a topic you'd > like to speak about, the program committee would love to consider it. > Please watch http://www.nanog.org/meetings/nanog59/callforpresentations for > more information. > > After considering feedback from members, speakers, ARIN, and sponsors we > have decided to make a small tweak to the program timing at NANOG 59. We > will continue with the Monday-Wednesday format, however we will move the > ARIN Track and Tutorials to Tuesday morning, highlighting their importance > to the program. The program will begin on Monday morning at 10:00AM > followed by our popular Newcomers Lunch. The exact schedule layout can be > found at http://www.nanog.org/meetings/nanog59/preagenda and is also > attached in JPG format to this email. > > > If you wish to submit a presentation, please keep these important dates > in mind: > > > Presentation Abstracts and Draft Slides Due: 16-Aug-2013 > Slides Due: > 30-Aug-2013 > Topic List Posted: > 06-Sep-2013 > Final Agenda Published: > 27-Sep-2013 > > Please submit your materials to http://pc.nanog.org > > Looking forward to seeing everyone in Phoenix! > > -Dave Temkin > > (Chair, NANOG Program Committee) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel_Alexander at Cable.Comcast.com Tue Jul 16 13:29:57 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 16 Jul 2013 17:29:57 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <69a24076fa5245f09272880a662a585b@BN1PR03MB250.namprd03.prod.outlook.com> Message-ID: Hello David, I touched on this issue back in April and think this is a topic worth discussing. As Chris mentioned in his reply, it is related to 2013-5:LIR/ISP and End-user Definitions, but I think this is a larger concept that the definitions will play a part. The lines between ISP's, end-user, and all other networks are blurry. There are global end-user networks that dwarf the networks of many ISP's. There are ISP networks serving ISP networks who serve ISP networks. And there are service networks that cross the boundaries of both definitions. I would contend that they all fall into a more generalized definition of Organizations operating networks providing connectivity to their users. Those users can be any number of things like members of a community, customers paying for a service, a student on campus, a hosting customer, or HR department. Before everyone nitpicks the paragraph above, I would like to clarify, that I don't think the distinctions should be abandoned. I simply think they should be refocused to what is relevant to an RIR. There are two general principles being discussed in 2013-4: RIR Principles that I think people can agree upon. One is that an RIR should make unique assignments. The other is that they should be able to keep track of them. I left this vague because I don't want to cross the streams of the two conversations. The point I'm trying to make is that the distinction between the network definitions may apply to how the resource assignments should be tracked, but they should be less of a factor in how the resources are obtained. This becomes even more relevant in todays world where transfers will soon outnumber assignments/allocations, and we see organizations redefining what they are in order to save on member fees, or meet different qualifying requirements. I think there should be a single set of parameters regarding minimum allocation size, timeframes, utilization requirements, and qualifying requirements. Somewhere we blurred the lines of how resources are allocated with how they should be tracked and the result is the dichotomy you mentioned. I also feel that this creation of classes is contrary to the stewardship our RIR policies should provide. As this discussion continues to develop I would like to see the distinction between PI and PA allocations and assignment requirements be removed. I would suggest they all be resource allocations that are given to a network operator, with possibly different requirements as to how they should be tracked. Thank you for reviving this conversation. Dan Alexander Speaking only for myself From: David Huberman Date: Mon, 15 Jul 2013 16:34:07 +0000 To: "arin-ppml at arin.net" Subject: [arin-ppml] Initial ISP Allocation Policy Hello, For 15 years, ARIN policy (derived from RFC2050) has promoted a dichotomy between provider networks and enterprise networks. I submit that the dichotomy between enterprises and providers is unbalanced, technically unjustified, and represents poor stewardship. I believe ARIN Policy should remove the barriers for provider networks who wish to begin numbering their network with space from the Registry. Under today?s Policy framework, it is very easy to get an initial assignment of IPv4 addresses from the Registry if you are a multi-homed enterprise network. Qualifying for a /24 is as simple as having a need to use 64 IPv4 addresses right away, and projecting a need for at least 128 IPv4 addresses within one year. This Policy is, in this writer?s opinion, very good. Under today?s Policy framework, it is not very easy, however, to get an initial allocation of IPv4 addresses from the Registry if you are a multi-homed provider network. Qualifying for the minimum allocation size of a /22 requires the network to already be utilizing a /23 equivalent from other providers or peers, and be willing and able to commit to ARIN to renumbering out of that space before being eligible for an additional allocation. Normally, I would submit a Draft Policy Proposal to offer a sound policy solution. Watching PPML over the last 10 years, however, has me shying away from a proposal because I sense there are too many who are against any changes to the IPv4 policy framework. I am, therefore, posting this message in hopes of taking the temperature of the policy community. I think a potential policy change is relevant at such a late date because the math clearly shows that the largest networks will be the ones who will be first unable to receive meaningful additional IPv4 address blocks from ARIN. The smallest of networks should be able to receive allocations and assignments from ARIN long after the large networks have exhausted. I think, therefore, that a fix to what I believe is an unfair policy would be relevant for a few years going forward. What do you think? With regards, David DAVID R Huberman Senior Program Manager Microsoft GFS 425-777-0259 (w) david.huberman at microsoft.com _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From SRyerse at eclipse-networks.com Tue Jul 16 14:40:22 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 16 Jul 2013 18:40:22 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <51E480E0.7070606@umn.edu> References: <01f601ce7e73$04068cc0 $0c13a640$@tndh.net><51DF46C3.9020900@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M A IL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli p se-networks.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips e-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> <51E480E0.7070606@umn.edu> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." It would have been nice if ARIN had let this community know of the change. The way I read the new Mission Statement it has changed a lot and I think the entire mission has changed. It doesn't even say that ARIN is supposed to Allocate Internet Resources anymore. Isn't this community supposed to have input to ARIN for as significant a change as a Mission Statement change? I wonder why it changed? Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: David Farmer [mailto:farmer at umn.edu] Sent: Monday, July 15, 2013 7:08 PM To: Steven Ryerse Cc: Matthew Wilder; Chris Grundemann; arin-ppml at arin.net; David Farmer Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On 7/15/13 17:53 , Steven Ryerse wrote: > So I infer from your comments that this community doesn't have to help create policies that align with ARIN's stated mission. Wow! So following that logic to the extreme then would it be OK for this community to create a policy that no more allocations of any kind will be made? I think not! So then is it OK for this community to create policies that's primary goal is to partially stop allocations? Using the exact same logic as I used above - I think not. I do think it is OK for this community to help create policies that right size allocations and I think that is covered in the Mission Statement. > > I humbly submit that ignorance of ARINs Mission Statement is the underlying problem why I think policy making in this community has gone off track. No policies have to align with the mission statement, or if they are far enough out of line with the mission statement the Board wouldn't approve a policy. However, the mission statement isn't as clear cut as you seem to think it is. ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach. The above mission statement allow a wide variety of things, the interpretation of which of those are good or bad is mostly up to the community. And I don't see how any of the proposed Principles in ARIN-2013-4 conflict with the mission statement. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jcurran at arin.net Tue Jul 16 14:50:33 2013 From: jcurran at arin.net (John Curran) Date: Tue, 16 Jul 2013 18:50:33 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqsVn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M> <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> <51E480E0.7070606@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> Message-ID: <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> On Jul 16, 2013, at 2:40 PM, Steven Ryerse wrote: > Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: > > ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? > > I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: > > "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." > > It would have been nice if ARIN had let this community know of the change. > I wonder why it changed? It was changed to make it clear that ARIN does not develop the policies, but instead "coordinates the development of policies by the community" (This is accomplished by mechanisms such as the ARIN Policy Development Process, maintenance of this Public Policy Mailing List, support of the the ARIN Advisory Council, etc.) Thanks, /John John Curran President and CEO ARIN From SRyerse at eclipse-networks.com Tue Jul 16 15:01:03 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 16 Jul 2013 19:01:03 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu><"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads><"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M ><"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli ><5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips><5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com><51E4 80E0.7070606@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> I certainly think that ARIN has the right to change the Mission Statement when it wants to. I would comment though that ARIN deciding to make a significant rewrite to the Mission Statement without this community's input first - sure does puncture the illusion that ARIN only changes policies with this community's consensus. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, July 16, 2013 2:51 PM To: Steven Ryerse Cc: David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Jul 16, 2013, at 2:40 PM, Steven Ryerse wrote: > Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: > > ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? > > I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: > > "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." > > It would have been nice if ARIN had let this community know of the change. > I wonder why it changed? It was changed to make it clear that ARIN does not develop the policies, but instead "coordinates the development of policies by the community" (This is accomplished by mechanisms such as the ARIN Policy Development Process, maintenance of this Public Policy Mailing List, support of the the ARIN Advisory Council, etc.) Thanks, /John John Curran President and CEO ARIN From jcurran at arin.net Tue Jul 16 15:09:42 2013 From: jcurran at arin.net (John Curran) Date: Tue, 16 Jul 2013 19:09:42 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M> <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <"e-networks.co m"@mac.com> <"5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296"@ENI-MAIL.eclipse-networks.com> <"51E4 80E0.7070606"@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> Message-ID: On Jul 16, 2013, at 3:01 PM, Steven Ryerse wrote: > I certainly think that ARIN has the right to change the Mission Statement when it wants to. I would comment though that ARIN deciding to make a significant rewrite to the Mission Statement without this community's input first - sure does puncture the illusion that ARIN only changes policies with this community's consensus. We have always distinguished number resource policy from operational matters; number resource policy is developed by the community whereas operational matters (budget, bylaws, mission, etc.) are under the purview of the member-elected ARIN Board of Trustees. FYI, /John John Curran President and CEO ARIN From Matthew.Wilder at telus.com Tue Jul 16 15:12:15 2013 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Tue, 16 Jul 2013 13:12:15 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu><"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads><"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M ><"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli ><5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips><5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com><51E4 80E0.7070606@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> Message-ID: If you analyze the changes in the mission statement, you will notice that the changes serve exactly the purpose of empowering the community as opposed to ARIN itself, so you're crying foul that ARIN is doing what you want them to. mw -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: July 16, 2013 12:01 PM To: John Curran Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised I certainly think that ARIN has the right to change the Mission Statement when it wants to. I would comment though that ARIN deciding to make a significant rewrite to the Mission Statement without this community's input first - sure does puncture the illusion that ARIN only changes policies with this community's consensus. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, July 16, 2013 2:51 PM To: Steven Ryerse Cc: David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Jul 16, 2013, at 2:40 PM, Steven Ryerse wrote: > Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: > > ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? > > I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: > > "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." > > It would have been nice if ARIN had let this community know of the change. > I wonder why it changed? It was changed to make it clear that ARIN does not develop the policies, but instead "coordinates the development of policies by the community" (This is accomplished by mechanisms such as the ARIN Policy Development Process, maintenance of this Public Policy Mailing List, support of the the ARIN Advisory Council, etc.) Thanks, /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Wed Jul 17 12:57:13 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 12:57:13 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0 $0c13a640$@tndh.net> <51DF46C3.9020900@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M A IL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli p se-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips e-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> <51E480E0.7070606@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> Message-ID: There was a notice sent out several months ago about the mission statement change. This was an action of the BoT. I remember receiving the notice. I don't remember which list(s) I received it on, but most likely arin-announce and/or arin-discuss. Owen Sent from my iPad On Jul 16, 2013, at 2:40 PM, Steven Ryerse wrote: > Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: > > ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? > > I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: > > "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." > > It would have been nice if ARIN had let this community know of the change. The way I read the new Mission Statement it has changed a lot and I think the entire mission has changed. It doesn't even say that ARIN is supposed to Allocate Internet Resources anymore. Isn't this community supposed to have input to ARIN for as significant a change as a Mission Statement change? > > I wonder why it changed? > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > > -----Original Message----- > From: David Farmer [mailto:farmer at umn.edu] > Sent: Monday, July 15, 2013 7:08 PM > To: Steven Ryerse > Cc: Matthew Wilder; Chris Grundemann; arin-ppml at arin.net; David Farmer > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > On 7/15/13 17:53 , Steven Ryerse wrote: >> So I infer from your comments that this community doesn't have to help create policies that align with ARIN's stated mission. Wow! So following that logic to the extreme then would it be OK for this community to create a policy that no more allocations of any kind will be made? I think not! So then is it OK for this community to create policies that's primary goal is to partially stop allocations? Using the exact same logic as I used above - I think not. I do think it is OK for this community to help create policies that right size allocations and I think that is covered in the Mission Statement. >> >> I humbly submit that ignorance of ARINs Mission Statement is the underlying problem why I think policy making in this community has gone off track. > > No policies have to align with the mission statement, or if they are far enough out of line with the mission statement the Board wouldn't approve a policy. However, the mission statement isn't as clear cut as you seem to think it is. > > ARIN, a nonprofit member-based organization, supports the operation > of the Internet through the management of Internet number resources > throughout its service region; coordinates the development of > policies by the community for the management of Internet Protocol > number resources; and advances the Internet through informational > outreach. > > The above mission statement allow a wide variety of things, the interpretation of which of those are good or bad is mostly up to the community. And I don't see how any of the proposed Principles in > ARIN-2013-4 conflict with the mission statement. > > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Wed Jul 17 13:13:24 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 13:13:24 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: > The point I'm trying to make is that the distinction between the network > definitions may apply to how the resource assignments should be tracked, > but they should be less of a factor in how the resources are obtained. > This becomes even more relevant in todays world where transfers will soon > outnumber assignments/allocations, and we see organizations redefining > what they are in order to save on member fees, or meet different > qualifying requirements. I think there should be a single set of > parameters regarding minimum allocation size, timeframes, utilization > requirements, and qualifying requirements. Respectfully, I disagree. The process of explaining how one will use resources within a network over which one retains exclusive control can be and often is quite different from the process needed in order to explain how one plans to delegate resources to other organizations and networks outside of one's exclusive control. Having made applications under both policy frameworks and having been active in authoring policies on both sides of the spectrum, I think that the needs of these two different communities in terms of how they justify resources are, in fact, quite distinct. I suggest this exercise for anyone who doubts this is the case... Imagine you are an IPv6 end-user wanting to apply under NRPM 6 for resources. You have a single site and are hoping to obtain a /48. Now, read through the LIR/ISP policy for IPv6 and imagine trying to write your justification under that policy. It makes no sense whatsoever. A little (very little) less nonsensical... Imagine you are an LIR/ISP with 3,100 serving sites located throughout the ARIN service region. Your largest serving site serves 40,000 customer end-sites. Now review the end-user policies in section 6 and imagine applying under those. Yes, there are many organizations which are hybrids of these two environments these days. In most cases, those organizations are better served by the LIR/ISP policy and should apply under those policies. That is one of the reasons I suggested that we mostly let organizations self-categorize and give staff guidance and support stating that if an organization does not clearly fit within the end-user definition, they should be treated as an LIR/ISP. > Somewhere we blurred the lines of how resources are allocated with how > they should be tracked and the result is the dichotomy you mentioned. I > also feel that this creation of classes is contrary to the stewardship our > RIR policies should provide. As this discussion continues to develop I > would like to see the distinction between PI and PA allocations and > assignment requirements be removed. I would suggest they all be resource > allocations that are given to a network operator, with possibly different > requirements as to how they should be tracked. I simply don't see how that could be workable. Could you propose policy language you feel would adequately implement such a structure? Thanks, Owen From bill at herrin.us Wed Jul 17 15:06:48 2013 From: bill at herrin.us (William Herrin) Date: Wed, 17 Jul 2013 15:06:48 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: On Wed, Jul 17, 2013 at 1:13 PM, Owen DeLong wrote: > Having made applications under both policy frameworks and > having been active in authoring policies on both sides of the > spectrum, I think that the needs of these two different > communities in terms of how they justify resources are, > in fact, quite distinct. I suggest this exercise for anyone > who doubts this is the case... Akamai assigns IP addresses to its servers for use with SSL. Akamai owns the servers. The servers cache content from other servers they don't own and then feed it up to the public on request. ISP or end-user? Why? Google assignes IP addresses to its servers for SSL. Google owns the servers. The servers cache content from other servers they don't own and index it for searching by google users. ISP or end-user? Why? The University of Maryland assigns IP addresses to students in dorms. The computers are owned by the students and do everything from web surfing to bit torrent to servers. ISP or end-user? Why? Starbucks Coffee runs wifi hot spots. Many many wifi hotspots. ISP or end-user? Why? Hilton and Marriott provide Internet service to their customers during their stays. ISP or end-user? Why? Linode assigns IP addresses to virtual servers running only on equipment they own. Each virtual server is leased to a customer. ISP or end-user? Why? Godaddy vends DNS service to half the Internet using only equipment they own. ISP or end-user? Why? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From JKrejci at usinternet.com Wed Jul 17 16:02:46 2013 From: JKrejci at usinternet.com (Justin Krejci) Date: Wed, 17 Jul 2013 20:02:46 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> , Message-ID: 1374091914684-020-01069253.jkrejci.usinternet.com@USI-2K10EX01-MT.usicorp.usinternet.com Here is my newbie and possibly naive response. Without additional details on individual cases in the list, I would expect all of those cases to be "end-users" as none of them are in the business of reallocating address blocks. Right or wrong I've always been under the impression this to be the general rule of thumb: if allowed to reallocate then you're an ISP, else end-user; maybe to back up even further the primary purpose of the listed organizations are not to provide Internet connectivity services nor is it their primary goal or likely even a secondary goal. Akamai, provide effective access to 3rd party content Google, provide advertising, searching, and various web related services U of Maryland, provide education Starbucks, provide beverages and calories in solid form Hilton/Marriott, provide hospitality Linode, provide virtual server hosting Godaddy, provide DNS/web hosting In any case, NRPM 2.6 says, "An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks." I think all of these example cases seem to fit this wording as they are operating their identified systems within their operational networks. Maybe "operational networks" could be construed to mean a variety of things, some which may conflict with one another, I don't know. ________________________________________ From: William Herrin [bill at herrin.us] Sent: Wednesday, July 17, 2013 2:06 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Initial ISP Allocation Policy On Wed, Jul 17, 2013 at 1:13 PM, Owen DeLong wrote: > Having made applications under both policy frameworks and > having been active in authoring policies on both sides of the > spectrum, I think that the needs of these two different > communities in terms of how they justify resources are, > in fact, quite distinct. I suggest this exercise for anyone > who doubts this is the case... Akamai assigns IP addresses to its servers for use with SSL. Akamai owns the servers. The servers cache content from other servers they don't own and then feed it up to the public on request. ISP or end-user? Why? Google assignes IP addresses to its servers for SSL. Google owns the servers. The servers cache content from other servers they don't own and index it for searching by google users. ISP or end-user? Why? The University of Maryland assigns IP addresses to students in dorms. The computers are owned by the students and do everything from web surfing to bit torrent to servers. ISP or end-user? Why? Starbucks Coffee runs wifi hot spots. Many many wifi hotspots. ISP or end-user? Why? Hilton and Marriott provide Internet service to their customers during their stays. ISP or end-user? Why? Linode assigns IP addresses to virtual servers running only on equipment they own. Each virtual server is leased to a customer. ISP or end-user? Why? Godaddy vends DNS service to half the Internet using only equipment they own. ISP or end-user? Why? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From Daniel_Alexander at Cable.Comcast.com Wed Jul 17 16:21:25 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Wed, 17 Jul 2013 20:21:25 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: Message-ID: Owen, Your reply sounds circular to me. Is the process of explaining resources complicated because they are end users or ISP's, or are they complicated because the policy requirements have made them so by creating all the distinctions? All the issues you mention are because the policies are different. I'm really not trying to give a cheap answer. It is a question to the larger point of the email. I was more curious about everyones thoughts on the high level concept. Should the distinctions in network definitions be applied to how resources are justified, tracked, or both? To make a change like this would require multiple proposals. David's initial ISP allocation question is a good place to start. Dan Alexander Speaking only for myself On 7/17/13 1:13 PM, "Owen DeLong" wrote: >> The point I'm trying to make is that the distinction between the network >> definitions may apply to how the resource assignments should be tracked, >> but they should be less of a factor in how the resources are obtained. >> This becomes even more relevant in todays world where transfers will >>soon >> outnumber assignments/allocations, and we see organizations redefining >> what they are in order to save on member fees, or meet different >> qualifying requirements. I think there should be a single set of >> parameters regarding minimum allocation size, timeframes, utilization >> requirements, and qualifying requirements. > >Respectfully, I disagree. > >The process of explaining how one will use resources within a network >over which one retains exclusive control can be and often is quite >different from the process needed in order to explain how one plans to >delegate resources to other organizations and networks outside of one's >exclusive control. > >Having made applications under both policy frameworks and having been >active in authoring policies on both sides of the spectrum, I think that >the needs of these two different communities in terms of how they justify >resources are, in fact, quite distinct. I suggest this exercise for >anyone who doubts this is the case... > >Imagine you are an IPv6 end-user wanting to apply under NRPM 6 for >resources. You have a single site and are hoping to obtain a /48. Now, >read through the LIR/ISP policy for IPv6 and imagine trying to write your >justification under that policy. It makes no sense whatsoever. > >A little (very little) less nonsensical... Imagine you are an LIR/ISP >with 3,100 serving sites located throughout the ARIN service region. Your >largest serving site serves 40,000 customer end-sites. Now review the >end-user policies in section 6 and imagine applying under those. > >Yes, there are many organizations which are hybrids of these two >environments these days. In most cases, those organizations are better >served by the LIR/ISP policy and should apply under those policies. That >is one of the reasons I suggested that we mostly let organizations >self-categorize and give staff guidance and support stating that if an >organization does not clearly fit within the end-user definition, they >should be treated as an LIR/ISP. > >> Somewhere we blurred the lines of how resources are allocated with how >> they should be tracked and the result is the dichotomy you mentioned. I >> also feel that this creation of classes is contrary to the stewardship >>our >> RIR policies should provide. As this discussion continues to develop I >> would like to see the distinction between PI and PA allocations and >> assignment requirements be removed. I would suggest they all be resource >> allocations that are given to a network operator, with possibly >>different >> requirements as to how they should be tracked. > >I simply don't see how that could be workable. Could you propose policy >language you feel would adequately implement such a structure? > >Thanks, > >Owen > From owen at delong.com Wed Jul 17 16:21:04 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 15:51:04 -0430 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><51DF46C3.9020900@umn.edu> <5B9E90747FA29 74D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> Message-ID: <4484986C-C756-4922-8E95-BF150757A6E4@delong.com> You've just described pretty much what happens now. This is, to me at least, indistinguishable other than a few subtle operational details from the current needs-basis policy and process(es). Owen On Jul 15, 2013, at 3:53 PM, Steven Ryerse wrote: > If you are publicly traded and your company?s revenues are public then the size of the company is available to all. This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large block size. The other info that could be used is how much resource does an org have now. If they have a /8 they might really have use for another /8. If they have a /22 they might really have use for another /22. Obviously the org with a /22 isn?t likely to have use for a /8. Orgs with multiple allocations already can add them together including legacy blocks. An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 . The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle. I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required. In this way the blocks allocated are right sized for the size of the org requesting the allocation. There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: Blake Dunlap [mailto:ikiris at gmail.com] > Sent: Monday, July 15, 2013 3:01 PM > To: Steven Ryerse > Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > Exactly how is this "right sized allocation" based on network size different than needs basis allocation? > > -Blake > > > On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse wrote: > Note that I did say "right sized allocations" and have said multiple times that it is fine to match allocations with the size of the organization and/or the size of the organization's current network. I also have stated that we need to be good technical stewards and I think most folks here agree with that. I do not think a small organization like ours for example should ever get the technical equivalent of a /8 or even close to it. I do strongly think that every organization should be able to get a right sized allocation if they are going to use it as that grows the Internet - which in case folks forget is ARIN's mission. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] > Sent: Friday, July 12, 2013 12:18 PM > To: Steven Ryerse; David Farmer > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore. > > To be clear, IP Address schemes can only be updated so far. As far as I can tell IPv4 address schemes have never extended beyond the initial 32 bits they started off with, and IPv6 also will not change from a 128 bit address length. Granted, CIDR was introduced to IPv4 to extend the timeline for exhaust of IPv4 address resources, but this is exceptional, and not the rule (certainly for the future). > > And the cost you mention is not a negligible one. Think of the amount of time and energy that has already gone into IPv6 only to approach 2% of global IP traffic on IPv6. I believe it is in the community's best interest to conserve the word conservation in some form. As David said, the conservation of IPv6 resources is going to be much different than conservation of IPv4 resources. > > By the way, for those not following, there is a push from many member nations of the ITU and others in the international community to redistribute the governance of the internet in their interests. Do not be surprised if the nations gain the ability to allocate IP Address resources to the entities within their borders. In that world, IPv6 exhaust is only a short matter of time. If we can at least embed the concept of conservation of IPv6 resources now in some way, the global community will thank us a generation or two from now. > > mw > > On July 12, 2013 at 08:50 AM, "Steven Ryerse" wrote: > > > I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all - we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them. > > > > Bill is right that the word conserve needs to be removed. > > > Sent from my iPhone > > > On Jul 11, 2013, at 7:59 PM, "David Farmer" wrote: > > > > I really don't understand this debate on Conservation. :{ > > > > > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > > > > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > > > > > > Then others are not willing to concede that anything changes with IPv4 run-out. > > > > > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... > > > > > > So how do we move forward? I suggest; > > > > > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. > > > > > > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. > > > > > > 3. Are there other concepts, principles, or goals that were missing? > > > I suggested earlier that there were additional principles we should > > > be looking at. An candidates has come up in the conversation today > > > that I would like to propose; > > > > > > 0.2 Fair Distribution > > > > > > The principle of Fair Distribution is the precept that the > > > fundamental purpose of Internet number resources management is to > > > distributed unique number resources in a fair and impartial manner > > > to entities building and operating networks, for benefit of all > > > Internet users equally, and thereby facilitating the growth and > > > sustainability of the Internet. > > > > > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" > > > > > > Thanks > > > -- > > > ================================================ > > > David Farmer Email: farmer at umn.edu > > > Office of Information Technology > > > University of Minnesota > > > 2218 University Ave SE Phone: 1-612-626-0815 > > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > > ================================================ > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Jul 17 17:04:40 2013 From: bill at herrin.us (William Herrin) Date: Wed, 17 Jul 2013 17:04:40 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Wed, Jul 17, 2013 at 4:02 PM, Justin Krejci wrote: > Here is my newbie and possibly naive response. > > Without additional details on individual cases in the list, I would expect all of those cases to be "end-users" as none of them are in the business of reallocating address blocks. Right or wrong I've always been under the impression this to be the general rule of thumb: if allowed to reallocate then you're an ISP, else end-user; maybe to back up even further the primary purpose of the listed organizations are not to provide Internet connectivity services nor is it their primary goal or likely even a secondary goal. > > Akamai, provide effective access to 3rd party content > Google, provide advertising, searching, and various web related services > U of Maryland, provide education > Starbucks, provide beverages and calories in solid form > Hilton/Marriott, provide hospitality > Linode, provide virtual server hosting > Godaddy, provide DNS/web hosting > > In any case, NRPM 2.6 says, "An end-user is an organization receiving > assignments of IP addresses exclusively for use in its operational > networks." I think all of these example cases seem to fit this wording > as they are operating their identified systems within their operational > networks. Hi Justin, What about Verizon Wireless? They're primarily a cellular phone company, and the overwhelming majority of the phones on which IP addresses are used are still on the rent-to-own plan where you have to complete the 2 year contract before you actually own the phone. Untill then you're just leasing the use of their equipment. ISP or end-user? What about Comcast? They're in the business of providing cable television service. They'll also provide you with Internet access on the same coax cable with the modem they rent you. ISP or end-user? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed Jul 17 17:05:24 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 16:35:24 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: <6812CCE1-BD86-44A0-8714-4251A47B8491@delong.com> On Jul 17, 2013, at 2:36 PM, William Herrin wrote: > On Wed, Jul 17, 2013 at 1:13 PM, Owen DeLong wrote: >> Having made applications under both policy frameworks and >> having been active in authoring policies on both sides of the >> spectrum, I think that the needs of these two different >> communities in terms of how they justify resources are, >> in fact, quite distinct. I suggest this exercise for anyone >> who doubts this is the case... > > Akamai assigns IP addresses to its servers for use with SSL. Akamai > owns the servers. The servers cache content from other servers they > don't own and then feed it up to the public on request. > > ISP or end-user? Why? Generally, I would say end-user. My understanding is that mostly, Akamai uses blocks from the upstreams for each cluster which are assigned to them for use on the cluster. When I worked for Netli (which is now part of Akamai), we certainly applied as an end-user for our addresses that were used in that manner. End-user because we were not making assignments to systems we did not control. > Google assignes IP addresses to its servers for SSL. Google owns the > servers. The servers cache content from other servers they don't own > and index it for searching by google users. > > ISP or end-user? Why? Same answer as for Akamai and for the same reasons. OTOH, if you asked about Google Fiber, then clearly that is an ISP and it is a different situation. > The University of Maryland assigns IP addresses to students in dorms. > The computers are owned by the students and do everything from web > surfing to bit torrent to servers. > > ISP or end-user? Why? I could accept the university applying under either policy and self-determining so long as the university was not SWIPing blocks to those students and was willing to take responsibility for all uses of that address space. The question of whether students in an academic institution (this is not limited to universities IMHO) are more like customers of an LIR/ISP or more like employees of a business is definitely one of the most vague use cases today. I would argue that it varies from university to university and that the university and ARIN staff should usually be able to come to mutual agreement on the classification based on appropriate guidance from policy. Hence my proposed much simpler wording for this policy. > Starbucks Coffee runs wifi hot spots. Many many wifi hotspots. > > ISP or end-user? Why? Each Starbucks itself is more like an end-user. They never register the addresses to the users and the users are making very transient use of those addresses. The entity that allocates blocks to the individual Starbucks locations is probably more of an LIR/ISP, however and probably should be registering those blocks to the locations. > Hilton and Marriott provide Internet service to their customers during > their stays. > > ISP or end-user? Why? I consider this to be an identical use case to the Starbucks question and the same answer would apply. > Linode assigns IP addresses to virtual servers running only on > equipment they own. Each virtual server is leased to a customer. > > ISP or end-user? Why? End-user. The addresses are being placed on hardware devices under their exclusive control. However, if Linode were to start assigning blocks of addresses to customers and wanted to be able to register those blocks in whois for purposes of delegation of responsibility and reputation matters, then they would become an ISP/LIR for that purpose, IMHO. > Godaddy vends DNS service to half the Internet using only equipment they own. > > ISP or end-user? Why? End-user. They are not delegating addresses to external entities and have no need to register delegations or sub-delegations. Owen From bill at herrin.us Wed Jul 17 17:13:38 2013 From: bill at herrin.us (William Herrin) Date: Wed, 17 Jul 2013 17:13:38 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <6812CCE1-BD86-44A0-8714-4251A47B8491@delong.com> References: <6812CCE1-BD86-44A0-8714-4251A47B8491@delong.com> Message-ID: On Wed, Jul 17, 2013 at 5:05 PM, Owen DeLong wrote: > On Jul 17, 2013, at 2:36 PM, William Herrin wrote: >> Google assignes IP addresses to its servers for SSL. Google owns the >> servers. The servers cache content from other servers they don't own >> and index it for searching by google users. >> >> ISP or end-user? Why? > > Same answer as for Akamai and for the same reasons. > > OTOH, if you asked about Google Fiber, then clearly that is an ISP and it is a different situation. Google Fiber is a small part of the company. Should they have to register with ARIN separately just for that one small piece? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed Jul 17 17:12:52 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 16:42:52 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: <8F44515E-C1C3-44F0-8BCC-CDCC491FCC54@delong.com> On Jul 17, 2013, at 3:51 PM, "Alexander, Daniel" wrote: > Owen, > > Your reply sounds circular to me. Is the process of explaining resources > complicated because they are end users or ISP's, or are they complicated > because the policy requirements have made them so by creating all the > distinctions? All the issues you mention are because the policies are > different. I'm really not trying to give a cheap answer. It is a question > to the larger point of the email. I don't believe that the current process is complicated. I believe that if we were to try and shoehorn everything into one process, it would be complicated. My intent was to express how the current end-user policy does not map well to an ISP/LIR and how the current ISP/LIR policy would not map well to an end-user. If you have language that you think could be used to meet both sets of users' needs, then I would be very interested in seeing that. I have tried to think of language that could do that and it seems an insurmountable task to me, but I am perfectly willing to accept that you may be more clever or better able to tackle that problem than I am. > I was more curious about everyones thoughts on the high level concept. > Should the distinctions in network definitions be applied to how resources > are justified, tracked, or both? I think they are at least necessary in terms of justification. I think that because of the fee implications, they should also apply to how they are tracked. Further, I think it would be very punitive to end-users to make them start paying the same fees as LIRs/ISPs. > To make a change like this would require multiple proposals. David's > initial ISP allocation question is a good place to start. I do agree that the initial ISP allocation policy for IPv4 probably may be worth tweaking, not because I think that longer prefixes should be issued to ISPs as David proposes, but because I believe that we should remove some of the deadly-embrace conditions that exist in that policy and perhaps make it somewhat easier to qualify for a base /22 regardless of an ISPs immediate ability to utilize all of the space within 3 months. However, for the free pool, I don't see much point in changing IPv4 policy at this point. However, since this would also affect a new entities ability to obtain resources through the transfer process, I would suggest that effort in this area may still be worth while. Owen > > Dan Alexander > Speaking only for myself > > > > On 7/17/13 1:13 PM, "Owen DeLong" wrote: > >>> The point I'm trying to make is that the distinction between the network >>> definitions may apply to how the resource assignments should be tracked, >>> but they should be less of a factor in how the resources are obtained. >>> This becomes even more relevant in todays world where transfers will >>> soon >>> outnumber assignments/allocations, and we see organizations redefining >>> what they are in order to save on member fees, or meet different >>> qualifying requirements. I think there should be a single set of >>> parameters regarding minimum allocation size, timeframes, utilization >>> requirements, and qualifying requirements. >> >> Respectfully, I disagree. >> >> The process of explaining how one will use resources within a network >> over which one retains exclusive control can be and often is quite >> different from the process needed in order to explain how one plans to >> delegate resources to other organizations and networks outside of one's >> exclusive control. >> >> Having made applications under both policy frameworks and having been >> active in authoring policies on both sides of the spectrum, I think that >> the needs of these two different communities in terms of how they justify >> resources are, in fact, quite distinct. I suggest this exercise for >> anyone who doubts this is the case... >> >> Imagine you are an IPv6 end-user wanting to apply under NRPM 6 for >> resources. You have a single site and are hoping to obtain a /48. Now, >> read through the LIR/ISP policy for IPv6 and imagine trying to write your >> justification under that policy. It makes no sense whatsoever. >> >> A little (very little) less nonsensical... Imagine you are an LIR/ISP >> with 3,100 serving sites located throughout the ARIN service region. Your >> largest serving site serves 40,000 customer end-sites. Now review the >> end-user policies in section 6 and imagine applying under those. >> >> Yes, there are many organizations which are hybrids of these two >> environments these days. In most cases, those organizations are better >> served by the LIR/ISP policy and should apply under those policies. That >> is one of the reasons I suggested that we mostly let organizations >> self-categorize and give staff guidance and support stating that if an >> organization does not clearly fit within the end-user definition, they >> should be treated as an LIR/ISP. >> >>> Somewhere we blurred the lines of how resources are allocated with how >>> they should be tracked and the result is the dichotomy you mentioned. I >>> also feel that this creation of classes is contrary to the stewardship >>> our >>> RIR policies should provide. As this discussion continues to develop I >>> would like to see the distinction between PI and PA allocations and >>> assignment requirements be removed. I would suggest they all be resource >>> allocations that are given to a network operator, with possibly >>> different >>> requirements as to how they should be tracked. >> >> I simply don't see how that could be workable. Could you propose policy >> language you feel would adequately implement such a structure? >> >> Thanks, >> >> Owen >> From owen at delong.com Wed Jul 17 17:18:40 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 16:48:40 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: > On Wed, Jul 17, 2013 at 4:02 PM, Justin Krejci wrote: >> Here is my newbie and possibly naive response. >> >> Without additional details on individual cases in the list, I would expect all of those cases to be "end-users" as none of them are in the business of reallocating address blocks. Right or wrong I've always been under the impression this to be the general rule of thumb: if allowed to reallocate then you're an ISP, else end-user; maybe to back up even further the primary purpose of the listed organizations are not to provide Internet connectivity services nor is it their primary goal or likely even a secondary goal. >> >> Akamai, provide effective access to 3rd party content >> Google, provide advertising, searching, and various web related services >> U of Maryland, provide education >> Starbucks, provide beverages and calories in solid form >> Hilton/Marriott, provide hospitality >> Linode, provide virtual server hosting >> Godaddy, provide DNS/web hosting >> >> In any case, NRPM 2.6 says, "An end-user is an organization receiving >> assignments of IP addresses exclusively for use in its operational >> networks." I think all of these example cases seem to fit this wording >> as they are operating their identified systems within their operational >> networks. > > Hi Justin, > > What about Verizon Wireless? They're primarily a cellular phone > company, and the overwhelming majority of the phones on which IP > addresses are used are still on the rent-to-own plan where you have to > complete the 2 year contract before you actually own the phone. Untill > then you're just leasing the use of their equipment. It's my understanding that it is inappropriate to name particular companies in this case, but the below applies equally well to $CELLCO, so I'll speak to that. That's not true. If you were leasing their equipment, then you could terminate the contract and give the equipment back to them. Instead, you have to reimburse them for the subsidy (and possibly more in most cases). You bought the phone at a reduced price. You agreed to a service contract in exchange for that reduced price. If you terminate the contract early, you are obliged to pay back said discount. That is to the same as leasing equipment they own. > ISP or end-user? ISP? $CELLCO generally assigns a block of addresses to the phone (at least my $CELLCO assigns a /64 to my phone) and should be registering those assignments. Further, they are also providing a service which is intended to provide internet access to customer-owned hardware (your lease argument doesn't actually hold water as stated above). Even if the hardware is leased, it still counts as hardware under the customer's control. > What about Comcast? They're in the business of providing cable > television service. They'll also provide you with Internet access on > the same coax cable with the modem they rent you. > > ISP or end-user? The service is intended to be used to connect customer-owned equipment to the internet. As such, they are clearly in the LIR/ISP realm. Owen From owen at delong.com Wed Jul 17 17:20:38 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 16:50:38 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <6812CCE1-BD86-44A0-8714-4251A47B8491@delong.com> Message-ID: <20E562A3-4A76-45F0-9E9A-F28021CDB96C@delong.com> On Jul 17, 2013, at 4:43 PM, William Herrin wrote: > On Wed, Jul 17, 2013 at 5:05 PM, Owen DeLong wrote: >> On Jul 17, 2013, at 2:36 PM, William Herrin wrote: >>> Google assignes IP addresses to its servers for SSL. Google owns the >>> servers. The servers cache content from other servers they don't own >>> and index it for searching by google users. >>> >>> ISP or end-user? Why? >> >> Same answer as for Akamai and for the same reasons. >> >> OTOH, if you asked about Google Fiber, then clearly that is an ISP and it is a different situation. > > Google Fiber is a small part of the company. Should they have to > register with ARIN separately just for that one small piece? Now we get to the more interesting situation. I would say that it is up to Google to choose whether to treat GF as a separate business unit with a separate organizational relationship with ARIN or whether to let GF make all of Google into an ISP for purposes of categorization. I think that the latter would unnecessarily complicate life for Google's other business units that mostly look like end-users, but that's Google's business decision to make and not mine. Owen From farmer at umn.edu Wed Jul 17 17:30:51 2013 From: farmer at umn.edu (David Farmer) Date: Wed, 17 Jul 2013 16:30:51 -0500 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <6812CCE1-BD86-44A0-8714-4251A47B8491@delong.com> Message-ID: <51E70D0B.3070505@umn.edu> On 7/17/13 16:13 , William Herrin wrote: > On Wed, Jul 17, 2013 at 5:05 PM, Owen DeLong wrote: >> On Jul 17, 2013, at 2:36 PM, William Herrin wrote: >>> Google assignes IP addresses to its servers for SSL. Google owns the >>> servers. The servers cache content from other servers they don't own >>> and index it for searching by google users. >>> >>> ISP or end-user? Why? >> >> Same answer as for Akamai and for the same reasons. >> >> OTOH, if you asked about Google Fiber, then clearly that is an ISP and it is a different situation. > > Google Fiber is a small part of the company. Should they have to > register with ARIN separately just for that one small piece? Should they have to no. But they very well may want to for any number of reasons, that go way beyond RIR policy issues. There are many organizations that have multiple business units that independently register as separate organizations with ARIN or the other RIRs, it seems reasonable that some of those logically separate organizations could be ISPs and others could be end-users. This flexibility should not be eliminated either, so let's be careful. A quick reminder, for many reasons it is better if we don't call out specific organization names in examples on PPML. Yes, it can make your examples more clear, but you also risk mis-characterizing the situation of real organizations. And, worst case you can even go as far as creating legal issues. If possible it is better to avoid specific organization names. Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bill at herrin.us Wed Jul 17 17:30:46 2013 From: bill at herrin.us (William Herrin) Date: Wed, 17 Jul 2013 17:30:46 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: > On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >> What about Comcast? They're in the business of providing cable >> television service. They'll also provide you with Internet access on >> the same coax cable with the modem they rent you. >> >> ISP or end-user? > > The service is intended to be used to connect customer-owned > equipment to the internet. As such, they are clearly in the LIR/ISP realm. Starbucks, Hilton, they have large sections of the operation dedicated to connecting customer-owned equipment to the Internet. You said: > Each Starbucks itself is more like an end-user. They never register the > addresses to the users and the users are making very transient use of those addresses. So does that mean that an ISP generally leases Internet service monthy or yearly but and end-user only leases Internet service hourly or daily? -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SRyerse at eclipse-networks.com Wed Jul 17 18:00:23 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 17 Jul 2013 22:00:23 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <39D8D428-269E-469A-859C-5CF27B5A5EC9@delong.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M > <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli > <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> <51E4 80E0.7070606@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> <39D8D428-269E-469A-859C-5CF27B5A5EC9@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013A431454@ENI-MAIL.eclipse-networks.com> Correct, the Missions Statement isn't policy but policies all need to flow from and be in alignment with the Mission Statement. It exists to help guide ARIN and this community in day to day matters. I don't know who wrote the original Mission Statement - maybe IANA and NSF and others were involved - I don't know for sure. I do know for sure that the number one function that ARIN was created for is to allocate Internet resources and of course at that time it was worldwide. It says so at the beginning of the old Missions Statement ("allocates Internet Protocol resources" - see below). The new Mission Statement just says ARIN is to manage resources ("supports the operation of the Internet through the management of Internet number resources" - see below). In my opinion these are very different. The first says ARIN is to allocate, and the second says ARIN only has to manage - and thus doesn't necessarily have to allocate. I have no way of knowing but I wonder if IANA is OK with a change like this. Would they need to approve of a significant Mission Statement change for an RIR? I don't know how that all works. I have many times pointed out in this community that a particular policy or policy proposal does/did not match the Missions Statement. I guess instead of working with this community to align policies with the Mission Statement, ARIN decided to make the Missions Statement fit the policies. As I said ARIN does have the right to change it without this community's input but it sure leaves a bad taste in my mouth for ARIN not to have sought this community's input on something as significant as a Mission Statement rewrite. In my humble opinion it feels like they went behind my (our?) back and deprived this community of the much needed opportunity to truly debate and have input to what we want the overall mission of ARIN to be. Just my two cents. :-( -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, July 17, 2013 1:03 PM To: Steven Ryerse Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised The mission statement is not policy. Policy is what is in the NRPM. In addition to policy (driven by the community process), ARIN also has operational guidelines and directives (set by management and the board), bylaws (set by the board), a corporate charter (I believe this is set by the board, but may also require a vote of the membership), a mission statement (set by the board, though to the best of my recollection, this is the first time it has changed), and probably some other documents that I am unaware of involved in its administration and/or operations. I agree it would have been better if the board had solicited community input prior to instantiating a new mission statement. However, since the mission statement has no impact on policy, per se, I also don't feel that doing so has any impact on whether or not the community controls the policy process. Owen Sent from my iPad On Jul 16, 2013, at 3:01 PM, Steven Ryerse wrote: > I certainly think that ARIN has the right to change the Mission Statement when it wants to. I would comment though that ARIN deciding to make a significant rewrite to the Mission Statement without this community's input first - sure does puncture the illusion that ARIN only changes policies with this community's consensus. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Tuesday, July 16, 2013 2:51 PM > To: Steven Ryerse > Cc: David Farmer; arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - > revised > > > On Jul 16, 2013, at 2:40 PM, Steven Ryerse wrote: > >> Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: >> >> ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? >> >> I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: >> >> "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." >> >> It would have been nice if ARIN had let this community know of the change. > > > >> I wonder why it changed? > > > It was changed to make it clear that ARIN does not develop the policies, but instead "coordinates the development of policies by the community" > (This is accomplished by mechanisms such as the ARIN Policy > Development Process, maintenance of this Public Policy Mailing List, > support of the the ARIN Advisory Council, etc.) > > Thanks, > /John > > John Curran > President and CEO > ARIN > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From george.herbert at gmail.com Wed Jul 17 18:24:32 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 17 Jul 2013 15:24:32 -0700 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: On Wed, Jul 17, 2013 at 2:30 PM, William Herrin wrote: > On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: > > On Jul 17, 2013, at 4:34 PM, William Herrin wrote: > >> What about Comcast? They're in the business of providing cable > >> television service. They'll also provide you with Internet access on > >> the same coax cable with the modem they rent you. > >> > >> ISP or end-user? > > > > The service is intended to be used to connect customer-owned > > equipment to the internet. As such, they are clearly in the LIR/ISP > realm. > > Starbucks, Hilton, they have large sections of the operation dedicated > to connecting customer-owned equipment to the Internet. You said: > > > Each Starbucks itself is more like an end-user. They never register the > > addresses to the users and the users are making very transient use of > those addresses. > > So does that mean that an ISP generally leases Internet service monthy > or yearly but and end-user only leases Internet service hourly or > daily? > > -Bill There was (still is, but not as commonly used) a distinction which is useful in this discussion - "Network Service Provider" - provides network blocks to people "Internet Service Provider" - provides individual internet access of some sort (big) end user would be providing either or both to internal systems / customer groups, depending on interior routing / subnetting / network management. There are other definitions of those, but those are relevant. In IPv6 land it gets more complicated, with /64 at least and usually /56s going to individuals, but they may be getting those dynamically and for a single endpoint device and some fudging of the boundary has happened there. But there's still clearly a "this is SWIPed netblock to a network customer" vs "this is an individual end user / end device". $COFFEESHOP central networking may allocate a netblock to each location, but they're internal customers not external. One can make the case that the individual access then makes the overall organization an ISP from there. $HOTELCHAIN central networking - same thing. -- -george william herbert george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Jul 17 18:34:31 2013 From: jcurran at arin.net (John Curran) Date: Wed, 17 Jul 2013 22:34:31 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013A431454@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M> <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <"e-networks.co m"@mac.com> <"5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296"@ENI-MAIL.eclipse-networks.com> <"51E4 80E0.7070606"@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> <39D8D428-269E-469A-859C-5CF27B5A5EC9@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013A431454@ENI-MAIL.eclipse-networks.com> Message-ID: <1C9F9156-DD1C-437B-A404-E52894FBEB8D@arin.net> On Jul 17, 2013, at 5:00 PM, Steven Ryerse wrote: > Correct, the Missions Statement isn't policy but policies all need to flow from and be in alignment with the Mission Statement. It exists to help guide ARIN and this community in day to day matters. I don't know who wrote the original Mission Statement - maybe IANA and NSF and others were involved - I don't know for sure. ARIN Board of Trustees. You can find it noted in the 2001 ARIN Annual Report in my Chairman's message on page 3. > I do know for sure that the number one function that ARIN was created for is to allocate Internet resources and of course at that time it was worldwide. It says so at the beginning of the old Missions Statement ("allocates Internet Protocol resources" - see below). The new Mission Statement just says ARIN is to manage resources ("supports the operation of the Internet through the management of Internet number resources" - see below). > > In my opinion these are very different. The first says ARIN is to allocate, and the second says ARIN only has to manage - and thus doesn't necessarily have to allocate. The omission of "allocate" was not intentional; it is one aspect of management. The fact that this could be read as omission does raise appropriate concerns about the process by which the Mission statement is changed - see more below. > I have no way of knowing but I wonder if IANA is OK with a change like this. Would they need to approve of a significant Mission Statement change for an RIR? I don't know how that all works. A very interesting question... I believe that there is an (implied) agreement that the RIR's will operate in accordance with ICANN ICP-2 but that is a very broad set of principles which is implemented in each region as they see fit. > I have many times pointed out in this community that a particular policy or policy proposal does/did not match the Missions Statement. I guess instead of working with this community to align policies with the Mission Statement, ARIN decided to make the Missions Statement fit the policies. It would be best if the policies (including any principles) were all included in the Number Resource Policy Manual. > As I said ARIN does have the right to change it without this community's input but it sure leaves a bad taste in my mouth for ARIN not to have sought this community's input on something as significant as a Mission Statement rewrite. In my humble opinion it feels like they went behind my (our?) back and deprived this community of the much needed opportunity to truly debate and have input to what we want the overall mission of ARIN to be. Just my two cents. :-( While the change was intended to improve clarity, the fact that it could be read otherwise is definitely an indication that the process of changing the Mission statement needs more care. I believe that (in the future) the ARIN consultation process should be used to apprise the community of any intended change and receive feedback thereon, and will proceed this way in the future if at all possible. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Wed Jul 17 18:42:11 2013 From: bill at herrin.us (William Herrin) Date: Wed, 17 Jul 2013 18:42:11 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: On Wed, Jul 17, 2013 at 6:24 PM, George Herbert wrote: > $COFFEESHOP central networking may allocate a netblock to each location, but > they're internal customers not external. One can make the case that the > individual access then makes the overall organization an ISP from there. > > $HOTELCHAIN central networking - same thing. A handful of responses so far, all of them divergent, none clear and concise. Someone hurry up and quote Justice Stewart. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jdaniels at forked.net Wed Jul 17 18:10:13 2013 From: jdaniels at forked.net (Jon Daniels) Date: Wed, 17 Jul 2013 15:10:13 -0700 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: Is a VPS company an ISP or an end user? ARIN told me in a ticket regarding an initial IPv4 end-user request (this is yesterday) that the virtual server (VPS) company i work for, is NOT an end-user, but is an ISP. Each virtual servers uses less than a /29, and we do not do SWIP, reallocate, or reassign any IP space. The company only provides virtual servers. On Wed, Jul 17, 2013 at 2:18 PM, Owen DeLong wrote: > > On Jul 17, 2013, at 4:34 PM, William Herrin wrote: > >> On Wed, Jul 17, 2013 at 4:02 PM, Justin Krejci wrote: >>> Here is my newbie and possibly naive response. >>> >>> Without additional details on individual cases in the list, I would expect all of those cases to be "end-users" as none of them are in the business of reallocating address blocks. Right or wrong I've always been under the impression this to be the general rule of thumb: if allowed to reallocate then you're an ISP, else end-user; maybe to back up even further the primary purpose of the listed organizations are not to provide Internet connectivity services nor is it their primary goal or likely even a secondary goal. >>> >>> Akamai, provide effective access to 3rd party content >>> Google, provide advertising, searching, and various web related services >>> U of Maryland, provide education >>> Starbucks, provide beverages and calories in solid form >>> Hilton/Marriott, provide hospitality >>> Linode, provide virtual server hosting >>> Godaddy, provide DNS/web hosting >>> >>> In any case, NRPM 2.6 says, "An end-user is an organization receiving >>> assignments of IP addresses exclusively for use in its operational >>> networks." I think all of these example cases seem to fit this wording >>> as they are operating their identified systems within their operational >>> networks. >> >> Hi Justin, >> >> What about Verizon Wireless? They're primarily a cellular phone >> company, and the overwhelming majority of the phones on which IP >> addresses are used are still on the rent-to-own plan where you have to >> complete the 2 year contract before you actually own the phone. Untill >> then you're just leasing the use of their equipment. > > It's my understanding that it is inappropriate to name particular companies in this case, but the below applies equally well to $CELLCO, so I'll speak to that. > > That's not true. If you were leasing their equipment, then you could terminate the contract and give the equipment back to them. Instead, you have to reimburse them for the subsidy (and possibly more in most cases). You bought the phone at a reduced price. You agreed to a service contract in exchange for that reduced price. If you terminate the contract early, you are obliged to pay back said discount. That is to the same as leasing equipment they own. > >> ISP or end-user? > > ISP? $CELLCO generally assigns a block of addresses to the phone (at least my $CELLCO assigns a /64 to my phone) and should be registering those assignments. Further, they are also providing a service which is intended to provide internet access to customer-owned hardware (your lease argument doesn't actually hold water as stated above). Even if the hardware is leased, it still counts as hardware under the customer's control. > >> What about Comcast? They're in the business of providing cable >> television service. They'll also provide you with Internet access on >> the same coax cable with the modem they rent you. >> >> ISP or end-user? > > The service is intended to be used to connect customer-owned equipment to the internet. As such, they are clearly in the LIR/ISP realm. > > 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 info at arin.net if you experience any issues. From owen at delong.com Wed Jul 17 20:49:41 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 20:19:41 -0430 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013A431454@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M > <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli > <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> <51E4 80E0.7070606@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> <39D8D428-269E-469A-859C-5CF27B5A5EC9@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013! A431454@ENI-MAIL.eclipse-networks.com> Message-ID: <57519C53-DECC-4956-B1E1-025E1DA5538A@delong.com> On Jul 17, 2013, at 5:30 PM, Steven Ryerse wrote: > Correct, the Missions Statement isn't policy but policies all need to flow from and be in alignment with the Mission Statement. It exists to help guide ARIN and this community in day to day matters. I don't know who wrote the original Mission Statement - maybe IANA and NSF and others were involved - I don't know for sure. You made the statement that the BoT changing the mission statement without community input was not in line with the claim that policies are developed by the community. I was pointing out the fallacy in that argument by pointing out that the mission statement was not policy. Policies are developed by the community. Other things about ARIN are not. At least not directly. > I do know for sure that the number one function that ARIN was created for is to allocate Internet resources and of course at that time it was worldwide. It says so at the beginning of the old Missions Statement ("allocates Internet Protocol resources" - see below). The new Mission Statement just says ARIN is to manage resources ("supports the operation of the Internet through the management of Internet number resources" - see below). Actually, by the time ARIN was created, it was not world wide. There were already two other RIRs in operation at the time ARIN was created, so ARIN's original service region was "Rest of World" meaning everywhere not served by RIPE-NCC or APNIC (both of which predated ARIN). LACNIC and later AfriNIC further reduced ARIN's service region (in fact, AfriNIC also reduced APNIC and RIPE's service regions, not sure about LACNIC). > In my opinion these are very different. The first says ARIN is to allocate, and the second says ARIN only has to manage - and thus doesn't necessarily have to allocate. At the time ARIN was created, managing internet resources consisted almost exclusively of the process of allocating resources from greenfield space. Things have changed since then. We now have transfers of IPv4 resources and ASNs, reclaimed and returned resources (to a much greater degree than when ARIN was created), inter-regional transactions, etc. As such, I think that the term manage has become more consistent with ARIN's current mission whereas allocate describes only a subset. > I have no way of knowing but I wonder if IANA is OK with a change like this. Would they need to approve of a significant Mission Statement change for an RIR? I don't know how that all works. Well, per the MoU, IANA policies (with respect to number resources) are governed by policies which achieve consensus through the independent policy development process in all 5 RIRs and are then ratified by the NRO NC and subsequently ratified by the ICANN Board. As such, I can't see how IANA could object to a change like this since IANA has no role in defining the policies of the RIRs, but, rather operates in the other direction? The collective RIRs through the NRO manage the IANA policies. > I have many times pointed out in this community that a particular policy or policy proposal does/did not match the Missions Statement. I guess instead of working with this community to align policies with the Mission Statement, ARIN decided to make the Missions Statement fit the policies. I think, rather, that the original mission statement was an artifact of the time when it was created and we live in a different time now. I do not believe that the change in the mission statement represents a change in mission or an adaptation of the mission statement to fit the policies nearly so much as it represents a change in wording to recognize the larger nature of the mission than was evident at the time of ARIN creation. If ARIN's sole responsibility is to allocate, then who should process reclamations, returns, transfers, and other aspects of management of the address space? How do you see such a structure working? > As I said ARIN does have the right to change it without this community's input but it sure leaves a bad taste in my mouth for ARIN not to have sought this community's input on something as significant as a Mission Statement rewrite. In my humble opinion it feels like they went behind my (our?) back and deprived this community of the much needed opportunity to truly debate and have input to what we want the overall mission of ARIN to be. Just my two cents. :-( It left a bad taste in my mouth as well. I informed several board members of that fact at the time. I don't think that it was their intent to go behind anyone's back. Indeed, I think it was out-of-control group-think on the word smithing when they set out to clarify that the policies are, in fact, set by the community. Having talked to most of the people responsible for the change, I don't believe that any of them felt that the change was meaningful beyond the clarification intended. I was actually more upset about the loss of the "principles of stewardship" at the time. I still don't see the change from allocate to manage as being a material change to the mission statement (or to the mission) so much as a recognition of the current reality. Owen > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, July 17, 2013 1:03 PM > To: Steven Ryerse > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > The mission statement is not policy. > > Policy is what is in the NRPM. In addition to policy (driven by the community process), ARIN also has operational guidelines and directives (set by management and the board), bylaws (set by the board), a corporate charter (I believe this is set by the board, but may also require a vote of the membership), a mission statement (set by the board, though to the best of my recollection, this is the first time it has changed), and probably some other documents that I am unaware of involved in its administration and/or operations. > > I agree it would have been better if the board had solicited community input prior to instantiating a new mission statement. However, since the mission statement has no impact on policy, per se, I also don't feel that doing so has any impact on whether or not the community controls the policy process. > > Owen > > > Sent from my iPad > > On Jul 16, 2013, at 3:01 PM, Steven Ryerse wrote: > >> I certainly think that ARIN has the right to change the Mission Statement when it wants to. I would comment though that ARIN deciding to make a significant rewrite to the Mission Statement without this community's input first - sure does puncture the illusion that ARIN only changes policies with this community's consensus. >> >> Steven L Ryerse >> President >> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >> 770.656.1460 - Cell >> 770.399.9099 - Office >> 770.392-0076 - Fax >> >> ? Eclipse Networks, Inc. >> Conquering Complex Networks? >> >> >> -----Original Message----- >> From: John Curran [mailto:jcurran at arin.net] >> Sent: Tuesday, July 16, 2013 2:51 PM >> To: Steven Ryerse >> Cc: David Farmer; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - >> revised >> >> >> On Jul 16, 2013, at 2:40 PM, Steven Ryerse wrote: >> >>> Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: >>> >>> ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? >>> >>> I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: >>> >>> "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." >>> >>> It would have been nice if ARIN had let this community know of the change. >> >> >> >>> I wonder why it changed? >> >> >> It was changed to make it clear that ARIN does not develop the policies, but instead "coordinates the development of policies by the community" >> (This is accomplished by mechanisms such as the ARIN Policy >> Development Process, maintenance of this Public Policy Mailing List, >> support of the the ARIN Advisory Council, etc.) >> >> Thanks, >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. From owen at delong.com Wed Jul 17 20:54:05 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 20:24:05 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: On Jul 17, 2013, at 5:00 PM, William Herrin wrote: > On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: >> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >>> What about Comcast? They're in the business of providing cable >>> television service. They'll also provide you with Internet access on >>> the same coax cable with the modem they rent you. >>> >>> ISP or end-user? >> >> The service is intended to be used to connect customer-owned >> equipment to the internet. As such, they are clearly in the LIR/ISP realm. > > Starbucks, Hilton, they have large sections of the operation dedicated > to connecting customer-owned equipment to the Internet. You said: > Permit me to rephrase? The service (in the case of Comcast) is intended to connect customer-owned networking equipment to the internet (e.g. routers, bridges, etc.). In the case of Starbucks, Hilton, etc., the expectation is that you are connecting a terminal host and not a packet forwarding device. >> Each Starbucks itself is more like an end-user. They never register the >> addresses to the users and the users are making very transient use of those addresses. > > So does that mean that an ISP generally leases Internet service monthy > or yearly but and end-user only leases Internet service hourly or > daily? See above. I think getting into this level of semantic detail is a clear case of reductio ad absurdum. Owen From owen at delong.com Wed Jul 17 20:56:59 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jul 2013 20:26:59 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: Personally, I think ARIN is in error in that interpretation, but that is just my personal opinion and carries no actual weight with anyone other than me. I would suggest that you contact Leslie or John and request that your situation be reviewed by management. I know that there are a number of VPS companies that operate as end-users and I have even helped some of them to prepare their ARIN applications. Owen On Jul 17, 2013, at 5:40 PM, Jon Daniels wrote: > Is a VPS company an ISP or an end user? > > ARIN told me in a ticket regarding an initial IPv4 end-user request > (this is yesterday) that the virtual server (VPS) company i work for, > is NOT an end-user, but is an ISP. Each virtual servers uses less > than a /29, and we do not do SWIP, reallocate, or reassign any IP > space. The company only provides virtual servers. > > > > On Wed, Jul 17, 2013 at 2:18 PM, Owen DeLong wrote: >> >> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >> >>> On Wed, Jul 17, 2013 at 4:02 PM, Justin Krejci wrote: >>>> Here is my newbie and possibly naive response. >>>> >>>> Without additional details on individual cases in the list, I would expect all of those cases to be "end-users" as none of them are in the business of reallocating address blocks. Right or wrong I've always been under the impression this to be the general rule of thumb: if allowed to reallocate then you're an ISP, else end-user; maybe to back up even further the primary purpose of the listed organizations are not to provide Internet connectivity services nor is it their primary goal or likely even a secondary goal. >>>> >>>> Akamai, provide effective access to 3rd party content >>>> Google, provide advertising, searching, and various web related services >>>> U of Maryland, provide education >>>> Starbucks, provide beverages and calories in solid form >>>> Hilton/Marriott, provide hospitality >>>> Linode, provide virtual server hosting >>>> Godaddy, provide DNS/web hosting >>>> >>>> In any case, NRPM 2.6 says, "An end-user is an organization receiving >>>> assignments of IP addresses exclusively for use in its operational >>>> networks." I think all of these example cases seem to fit this wording >>>> as they are operating their identified systems within their operational >>>> networks. >>> >>> Hi Justin, >>> >>> What about Verizon Wireless? They're primarily a cellular phone >>> company, and the overwhelming majority of the phones on which IP >>> addresses are used are still on the rent-to-own plan where you have to >>> complete the 2 year contract before you actually own the phone. Untill >>> then you're just leasing the use of their equipment. >> >> It's my understanding that it is inappropriate to name particular companies in this case, but the below applies equally well to $CELLCO, so I'll speak to that. >> >> That's not true. If you were leasing their equipment, then you could terminate the contract and give the equipment back to them. Instead, you have to reimburse them for the subsidy (and possibly more in most cases). You bought the phone at a reduced price. You agreed to a service contract in exchange for that reduced price. If you terminate the contract early, you are obliged to pay back said discount. That is to the same as leasing equipment they own. >> >>> ISP or end-user? >> >> ISP? $CELLCO generally assigns a block of addresses to the phone (at least my $CELLCO assigns a /64 to my phone) and should be registering those assignments. Further, they are also providing a service which is intended to provide internet access to customer-owned hardware (your lease argument doesn't actually hold water as stated above). Even if the hardware is leased, it still counts as hardware under the customer's control. >> >>> What about Comcast? They're in the business of providing cable >>> television service. They'll also provide you with Internet access on >>> the same coax cable with the modem they rent you. >>> >>> ISP or end-user? >> >> The service is intended to be used to connect customer-owned equipment to the internet. As such, they are clearly in the LIR/ISP realm. >> >> 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 info at arin.net if you experience any issues. From SRyerse at eclipse-networks.com Wed Jul 17 23:58:19 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 18 Jul 2013 03:58:19 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <4484986C-C756-4922-8E95-BF150757A6E4@delong.com> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net><51DF46C3.9020900@umn.edu> <5B9E90747FA29 74D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> <4484986C-C756-4922-8E95-BF150757A6E4@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013A434C7B@ENI-MAIL.eclipse-networks.com> I don?t view this to be needs based at all, I view it to be a way to right size allocations without the needs tests. For example nowhere does it ask for router ARP logs or any other form of proof of need nor does it ask how long it will take to use up the allocation. It just asks what size network are you now with size of org thrown in for larger allocation requests. It also empowers ARIN management to consider unusual situations and allows ARIN to give a positive allocation if ARIN deems it reasonable after discussion. It simplifies a lot and could replace several policies. It removes the need to even define which org is an end user and which org is an ISP. It levels the playing field which in my opinion needs to be done. I think this is pretty far from the current allocation policies. This is a simple way to accomplish what has been proposed for RIPE to remove all of the needs test from their policies. Simple is good and simple is fair. From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, July 17, 2013 4:21 PM To: Steven Ryerse Cc: Blake Dunlap; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised You've just described pretty much what happens now. This is, to me at least, indistinguishable other than a few subtle operational details from the current needs-basis policy and process(es). Owen On Jul 15, 2013, at 3:53 PM, Steven Ryerse > wrote: If you are publicly traded and your company?s revenues are public then the size of the company is available to all. This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large block size. The other info that could be used is how much resource does an org have now. If they have a /8 they might really have use for another /8. If they have a /22 they might really have use for another /22. Obviously the org with a /22 isn?t likely to have use for a /8. Orgs with multiple allocations already can add them together including legacy blocks. An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 . The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle. I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required. In this way the blocks allocated are right sized for the size of the org requesting the allocation. There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. Conquering Complex Networks? From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Monday, July 15, 2013 3:01 PM To: Steven Ryerse Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised Exactly how is this "right sized allocation" based on network size different than needs basis allocation? -Blake On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse > wrote: Note that I did say "right sized allocations" and have said multiple times that it is fine to match allocations with the size of the organization and/or the size of the organization's current network. I also have stated that we need to be good technical stewards and I think most folks here agree with that. I do not think a small organization like ours for example should ever get the technical equivalent of a /8 or even close to it. I do strongly think that every organization should be able to get a right sized allocation if they are going to use it as that grows the Internet - which in case folks forget is ARIN's mission. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] Sent: Friday, July 12, 2013 12:18 PM To: Steven Ryerse; David Farmer Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore. To be clear, IP Address schemes can only be updated so far. As far as I can tell IPv4 address schemes have never extended beyond the initial 32 bits they started off with, and IPv6 also will not change from a 128 bit address length. Granted, CIDR was introduced to IPv4 to extend the timeline for exhaust of IPv4 address resources, but this is exceptional, and not the rule (certainly for the future). And the cost you mention is not a negligible one. Think of the amount of time and energy that has already gone into IPv6 only to approach 2% of global IP traffic on IPv6. I believe it is in the community's best interest to conserve the word conservation in some form. As David said, the conservation of IPv6 resources is going to be much different than conservation of IPv4 resources. By the way, for those not following, there is a push from many member nations of the ITU and others in the international community to redistribute the governance of the internet in their interests. Do not be surprised if the nations gain the ability to allocate IP Address resources to the entities within their borders. In that world, IPv6 exhaust is only a short matter of time. If we can at least embed the concept of conservation of IPv6 resources now in some way, the global community will thank us a generation or two from now. mw On July 12, 2013 at 08:50 AM, "Steven Ryerse" > wrote: > I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all - we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them. > Bill is right that the word conserve needs to be removed. > Sent from my iPhone > On Jul 11, 2013, at 7:59 PM, "David Farmer" > wrote: > > I really don't understand this debate on Conservation. :{ > > > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > > > > Then others are not willing to concede that anything changes with IPv4 run-out. > > > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... > > > > So how do we move forward? I suggest; > > > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. > > > > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. > > > > 3. Are there other concepts, principles, or goals that were missing? > > I suggested earlier that there were additional principles we should > > be looking at. An candidates has come up in the conversation today > > that I would like to propose; > > > > 0.2 Fair Distribution > > > > The principle of Fair Distribution is the precept that the > > fundamental purpose of Internet number resources management is to > > distributed unique number resources in a fair and impartial manner > > to entities building and operating networks, for benefit of all > > Internet users equally, and thereby facilitating the growth and > > sustainability of the Internet. > > > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" > > > > Thanks > > -- > > ================================================ > > David Farmer Email: farmer at umn.edu > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 1-612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > ================================================ > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Jul 18 01:13:38 2013 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jul 2013 01:13:38 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: On Wed, Jul 17, 2013 at 8:54 PM, Owen DeLong wrote: > On Jul 17, 2013, at 5:00 PM, William Herrin wrote: >> On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: >>> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >>>> What about Comcast? They're in the business of providing cable >>>> television service. They'll also provide you with Internet access on >>>> the same coax cable with the modem they rent you. >>>> >>>> ISP or end-user? >>> >>> The service is intended to be used to connect customer-owned >>> equipment to the internet. As such, they are clearly in the LIR/ISP realm. >> >> Starbucks, Hilton, they have large sections of the operation dedicated >> to connecting customer-owned equipment to the Internet. > > Permit me to rephrase? The service (in the case of Comcast) is > intended to connect customer-owned networking equipment to the > internet (e.g. routers, bridges, etc.). In the case of Starbucks, > Hilton, etc., the expectation is that you are connecting a terminal > host and not a packet forwarding device. Huh? Comcast is an ISP because they give you a modem to connect between the coax and your ethernet port but Starbucks isn't because you connect to a wifi access point instead? > I think getting into this level of semantic detail is a clear case of reductio ad absurdum. I'll say it is! The point here is that 21st century networks don't look like the dialup+webhost ISP of 1997, nor do they look like the "our employees have Netscape and Eudora" end-user of 1997. Attempts to shoehorn 21st century networks into those obsolete definitions frankly come up looking pretty stupid. What we *do* see is organizations managing IP addresses in several ways: 1. assigned to organization-owned infrastructure under the control of the organization's employees 2. assigned long-term to exclusive use by the organization's customers or users 3. ephemerally assigned to exclusive use by the organization's customers or users 4. reserved for future use And we see that most organizations do a mix of all of these things, not one or the other. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SRyerse at eclipse-networks.com Thu Jul 18 01:23:28 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 18 Jul 2013 05:23:28 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <57519C53-DECC-4956-B1E1-025E1DA5538A@delong.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M > <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli > <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> <51E4 80E0.7070606@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> <39D8D428-269E-469A-859C-5CF27B5A5EC9@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013!A431454@ENI-MAIL.eclipse-networks.com> <57519C53-DECC-4956-B1E1-025E1DA5538A@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013A434F32@ENI-MAIL.eclipse-networks.com> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, July 17, 2013 8:50 PM To: Steven Ryerse Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Jul 17, 2013, at 5:30 PM, Steven Ryerse wrote: > Correct, the Missions Statement isn't policy but policies all need to flow from and be in alignment with the Mission Statement. It exists to help guide ARIN and this community in day to day matters. I don't know who wrote the original Mission Statement - maybe IANA and NSF and others were involved - I don't know for sure. >> You made the statement that the BoT changing the mission statement without community input was not in line with the claim that policies are developed by the community. I was pointing out the fallacy in that argument by pointing out that the mission statement was not policy. Policies are developed by the community. Other things about ARIN are not. At least not directly. I would say that if something big is contemplated such as a Mission Change, which is what I believe this new Mission Statement is, why would ARIN not automatically solicit input on a proposed Mission Statement change from this community? John has said many times including under oath that ARIN implements policies that this community wants. If ARIN changes the Mission Statement without soliciting input from this community on the proposed changes, then in my opinion ARIN is not honoring the spirit of their long standing commitment to include this community in policy decisions - since all policies should flow from and be aligned with the Mission Statement. > I do know for sure that the number one function that ARIN was created for is to allocate Internet resources and of course at that time it was worldwide. It says so at the beginning of the old Missions Statement ("allocates Internet Protocol resources" - see below). The new Mission Statement just says ARIN is to manage resources ("supports the operation of the Internet through the management of Internet number resources" - see below). >>Actually, by the time ARIN was created, it was not world wide. There were already two other RIRs in operation at the time ARIN was created, so ARIN's original service region was "Rest of World" meaning everywhere not served by RIPE-NCC or APNIC (both of which predated ARIN). LACNIC and later AfriNIC further reduced ARIN's service region (in fact, AfriNIC also reduced APNIC and RIPE's service regions, not sure about LACNIC). I stand corrected. > In my opinion these are very different. The first says ARIN is to allocate, and the second says ARIN only has to manage - and thus doesn't necessarily have to allocate. >>At the time ARIN was created, managing internet resources consisted almost exclusively of the process of allocating resources from greenfield space. Things have changed since then. We now have transfers of IPv4 resources and ASNs, reclaimed and returned resources (to a much greater degree than when ARIN was created), inter-regional transactions, etc. As such, I think that the term manage has become more consistent with ARIN's current mission whereas allocate describes only a subset. I disagree and maybe we agree that we disagree here, but this is at the heart of what I think has been wrong with policy making. Assuming by greenfield space you mean that there were plenty of IPv4 addresses available then, I don't see any reason why the depletion of IPv4 should change ARIN's Mission or change ARIN's primary mission to Allocate. I know others might disagree but I strongly believe this. Certainly the stewardship portion of the previous Mission Statement should be applied - and that stewardship function should make sure allocations were/are not made willy nilly, but I believe the stewardship responsibility wasn't meant to be used to NOT allocate ; or maybe somehow make sure that an allocation is used up in a certain amount of time or whatever. This is why I have recently proposed to right size allocations (and remove needs based tests) and then get the allocations out there to orgs that will use them - which by the way fulfills the "advancement of the Internet" portion of the previous Mission Statement. > I have no way of knowing but I wonder if IANA is OK with a change like this. Would they need to approve of a significant Mission Statement change for an RIR? I don't know how that all works. >>Well, per the MoU, IANA policies (with respect to number resources) are governed by policies which achieve consensus through the independent policy development process in all 5 RIRs and are then ratified by the NRO NC and subsequently ratified by the ICANN Board. As such, I can't see how IANA could object to a change like this since IANA has no role in defining the policies of the RIRs, but, rather operates in the other direction? The collective RIRs through the NRO manage the IANA policies. > I have many times pointed out in this community that a particular policy or policy proposal does/did not match the Missions Statement. I guess instead of working with this community to align policies with the Mission Statement, ARIN decided to make the Missions Statement fit the policies. >>I think, rather, that the original mission statement was an artifact of the time when it was created and we live in a different time now. I do not believe that the change in the mission statement represents a change in mission or an adaptation of the mission statement to fit the policies nearly so much as it represents a change in wording to recognize the larger nature of the mission than was evident at the time of ARIN creation. I think the previous Mission Statement is elegant and was constructed very well. Reading it now I think it still does an excellent job of describing ARIN's mission today. A simple change to it to add that the scope that ARIN is now focused on Internet resources in this geographical region is all it needs to be current. Maybe we agree to disagree here too, but I think the new Mission Statement does change the mission. WORDS ARE A POWERFUL THING. >>If ARIN's sole responsibility is to allocate, then who should process reclamations, returns, transfers, and other aspects of management of the address space? How do you see such a structure working? I only mentioned previously what I think is the most important change, and that is the allocation verbiage has been removed. I think the word "protocol" could be removed from the previous Mission Statement and it would include all that you list below. I think all portions of the previous Mission Statement are important and should be retained. > As I said ARIN does have the right to change it without this > community's input but it sure leaves a bad taste in my mouth for ARIN > not to have sought this community's input on something as significant > as a Mission Statement rewrite. In my humble opinion it feels like > they went behind my (our?) back and deprived this community of the > much needed opportunity to truly debate and have input to what we want > the overall mission of ARIN to be. Just my two cents. :-( >>It left a bad taste in my mouth as well. I informed several board members of that fact at the time. >>I don't think that it was their intent to go behind anyone's back. Indeed, I think it was out-of-control group-think on the word smithing when they set out to clarify that the policies are, in fact, set by the community. Having talked to most of the people responsible for the change, I don't believe that any of them felt that the change was meaningful beyond the clarification intended. >>I was actually more upset about the loss of the "principles of stewardship" at the time. I still don't see the change from allocate to manage as being a material change to the mission statement (or to the mission) so much as a recognition of the current reality. I think the second most important change to the Mission Statement is the removal of the word "stewardship" so I agree with you on that completely! There has been comments in this community about stewardship in a current policy proposal in the last week - but with that word specifically removed from the new Mission Statement - maybe we should no longer be discussing that. (I think we should be discussing stewardship by the way but now our mission is different here.) It's not too late for ARIN to submit the current Mission Statement to this community for input. Counting you Owen, there are at least two of us in this community that would have liked to have some input. Are you listening John? Steve >>Owen > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, July 17, 2013 1:03 PM > To: Steven Ryerse > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - > revised > > The mission statement is not policy. > > Policy is what is in the NRPM. In addition to policy (driven by the community process), ARIN also has operational guidelines and directives (set by management and the board), bylaws (set by the board), a corporate charter (I believe this is set by the board, but may also require a vote of the membership), a mission statement (set by the board, though to the best of my recollection, this is the first time it has changed), and probably some other documents that I am unaware of involved in its administration and/or operations. > > I agree it would have been better if the board had solicited community input prior to instantiating a new mission statement. However, since the mission statement has no impact on policy, per se, I also don't feel that doing so has any impact on whether or not the community controls the policy process. > > Owen > > > Sent from my iPad > > On Jul 16, 2013, at 3:01 PM, Steven Ryerse wrote: > >> I certainly think that ARIN has the right to change the Mission Statement when it wants to. I would comment though that ARIN deciding to make a significant rewrite to the Mission Statement without this community's input first - sure does puncture the illusion that ARIN only changes policies with this community's consensus. >> >> Steven L Ryerse >> President >> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >> 770.656.1460 - Cell >> 770.399.9099 - Office >> 770.392-0076 - Fax >> >> ? Eclipse Networks, Inc. >> Conquering Complex Networks? >> >> >> -----Original Message----- >> From: John Curran [mailto:jcurran at arin.net] >> Sent: Tuesday, July 16, 2013 2:51 PM >> To: Steven Ryerse >> Cc: David Farmer; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - >> revised >> >> >> On Jul 16, 2013, at 2:40 PM, Steven Ryerse wrote: >> >>> Well that's interesting. Last August I included a copy of the ARIN Mission Statement that I cut and pasted from ARINs web site into one of my comments to this community. This was the statement: >>> >>> ?Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach.? >>> >>> I looked at ARINs web site today since the Mission Statement below didn't look like what I remembered and lo and behold - the Mission Statement has changed. David is correct that it says: >>> >>> "ARIN, a nonprofit member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach." >>> >>> It would have been nice if ARIN had let this community know of the change. >> >> >> >>> I wonder why it changed? >> >> >> It was changed to make it clear that ARIN does not develop the policies, but instead "coordinates the development of policies by the community" >> (This is accomplished by mechanisms such as the ARIN Policy >> Development Process, maintenance of this Public Policy Mailing List, >> support of the the ARIN Advisory Council, etc.) >> >> Thanks, >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. From SRyerse at eclipse-networks.com Thu Jul 18 01:37:51 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 18 Jul 2013 05:37:51 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp. usinternet.com><51e6fab4.0a8ce50a.51 27.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com><647B46E4-5388-49DC-B7E7-3DD7D8EE3550 @delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013A434FDC@ENI-MAIL.eclipse-networks.com> Yup! There isn't a need to differentiate these organizations types in allocation policies, except if there is a technical requirement that ARIN has to address that only applies to one or a subset of organization types. Otherwise it is just an organization that wants to use the Internet and these all should be treated the same for fairness - and that fulfills ARIN's mission of advancing the Internet. Getting deep into these weeds is why allocation policies have become unnecessarily complicated. (I will note here that the new Mission Statement now uses the word "advances".) :-) -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, July 18, 2013 1:14 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Initial ISP Allocation Policy On Wed, Jul 17, 2013 at 8:54 PM, Owen DeLong wrote: > On Jul 17, 2013, at 5:00 PM, William Herrin wrote: >> On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: >>> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >>>> What about Comcast? They're in the business of providing cable >>>> television service. They'll also provide you with Internet access >>>> on the same coax cable with the modem they rent you. >>>> >>>> ISP or end-user? >>> >>> The service is intended to be used to connect customer-owned >>> equipment to the internet. As such, they are clearly in the LIR/ISP realm. >> >> Starbucks, Hilton, they have large sections of the operation >> dedicated to connecting customer-owned equipment to the Internet. > > Permit me to rephrase... The service (in the case of Comcast) is > intended to connect customer-owned networking equipment to the > internet (e.g. routers, bridges, etc.). In the case of Starbucks, > Hilton, etc., the expectation is that you are connecting a terminal > host and not a packet forwarding device. Huh? Comcast is an ISP because they give you a modem to connect between the coax and your ethernet port but Starbucks isn't because you connect to a wifi access point instead? > I think getting into this level of semantic detail is a clear case of reductio ad absurdum. I'll say it is! The point here is that 21st century networks don't look like the dialup+webhost ISP of 1997, nor do they look like the "our employees have Netscape and Eudora" end-user of 1997. Attempts to shoehorn 21st century networks into those obsolete definitions frankly come up looking pretty stupid. What we *do* see is organizations managing IP addresses in several ways: 1. assigned to organization-owned infrastructure under the control of the organization's employees 2. assigned long-term to exclusive use by the organization's customers or users 3. ephemerally assigned to exclusive use by the organization's customers or users 4. reserved for future use And we see that most organizations do a mix of all of these things, not one or the other. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From David.Huberman at microsoft.com Thu Jul 18 04:36:08 2013 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 18 Jul 2013 08:36:08 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> Hello everyone, I would like to thank everyone for a very good discussion in this thread. First I'll give a very brief summary of the discussion so far, and then I have a solution to float to the list for feedback. Myself, Dan, Bill, and Steven have posted in favor of the high level concept that the differentiation in ARIN policy between enterprise networks and provider networks is no longer productive or relevant. Owen may agree in principle, but cautions us to be very careful with how we proceed. He is concerned that an effective "one size fits all" solution may be very difficult to design. George offers us an alternative nomenclature to consider (NSP v. ISP). I would like to now shift the discussion to how we approach potentially collapsing the two categories into one so that future interactions with ARIN are conducted under policy language which is relevant in 2014 and beyond. I agree with Dan that a wholesale paradigm shift in ARIN policy can only be accomplished with multiple proposals. There would be quite a few sections to change (with each change requiring careful consideration by the community). Moreover, I think we must be sensitive to ARIN's need to react to the possible impacts to both the financial and workflow modeling that would result from any changes we propose. At the same time, incremental change in NRPM is actually really hard. If this were 5 years ago, I would probably work very hard to help effect incremental change. But I think ARIN and the community have together failed to react to changes in the market over the last 15 years, and it is time to consider very big change. Let's get NRPM into a sane state for 2014 and beyond. In an effort to roll up sleeves and be productive, please indulge me while I lay out one potential vision for what a sane NRPM might look like. I warn you, good reader, that some of what I propose is very radical. - A section on obtaining initial IPv4 addresses from ARIN. No distinction between end-users and ISPs. No distinction between single-homed and multi-homed deployments (*if you don't understand why the difference has no virtue, ping me on or off list and I will show you the math as I see it). Text might look something like: "In order to receive an initial allocation from ARIN, an organization must: - demonstrate they operate an IP network that requires IPv4 addresses to deploy and/or grow; and - provide a numbering plan detailing how IPv4 addresses will be used in the first 180 days upon receiving an allocation. ARIN will review and verify the data provided, and provide for the organization's 6 month need." - A section on obtaining additional blocks, which still outlines the 80% rule. ("If you've efficiently used what you have, you can have more" is a technically sound concept that does not need much fixing.) Platform differences which are already fleshed out in NRPM (e.g., residential market area provider networks with their different metrics than more common buildouts) can and should remain. - We would have to figure out what to do with the requirement to SWIP, as the requirement is predicated on the classification of "ISP" actually existing (which it would not). That might need a working group to reconcile. - A section on obtaining initial IPv6 addresses from ARIN. Given that IPv6 is still very much in its infancy, I really would like to see very simple NRPM text which allows requestors to self-select what size block they need. The only barrier to abuse or silliness would be the fee schedule. It is arrogant and technically indefensible that ARIN policy today tries to dictate what a network does, and does not, justify as far as block size. IPv6 is much too immature for ARIN policy to presume such wisdom. - A section on obtaining additional IPv6 addresses from ARIN. Existing text in 6.5.3 is probably good enough for today, as there are only a handful of networks in the world with any experience needing additional IPv6 addresses due to efficient use of an initial block. Obtaining additional IPv6 addresses is a topic for many years from now, not today. Do you think any of this has value? Would it accomplish the overarching goal of improving ARIN policy to make it relevant to network operators in 2014 and beyond? What would your sane NRPM look like? With regards, David From jcurran at arin.net Thu Jul 18 08:58:03 2013 From: jcurran at arin.net (John Curran) Date: Thu, 18 Jul 2013 12:58:03 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013A434F32@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M> <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <"e-networks.co m"@mac.com> <"5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296"@ENI-MAIL.eclipse-networks.com> <"51E4 80E0.7070606"@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> <39D8D428-269E-469A-859C-5CF27B5A5EC9@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013!A431454@ENI-MAIL.eclipse-networks.com> <57519C53-DECC-4956-B1E1-025E1DA5538A@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013A434F32@ENI-MAIL.eclipse-networks.com> Message-ID: <3E84A41D-B879-4A83-9A02-8D6AEA8A537A@arin.net> On Jul 18, 2013, at 12:23 AM, Steven Ryerse wrote: > I would say that if something big is contemplated such as a Mission Change, which is what I believe this new Mission Statement is, why would ARIN not automatically solicit input on a proposed Mission Statement change from this community? You believe that the update was a major change to the mission, but in truth it was simply an attempt to more accurately reflect the current mission. > John has said many times including under oath that ARIN implements policies that this community wants. If ARIN changes the Mission Statement without soliciting input from this community on the proposed changes, then in my opinion ARIN is not honoring the spirit of their long standing commitment to include this community in policy decisions - since all policies should flow from and be aligned with the Mission Statement. We likely have a fundamental disagree on that point, in that the mission statement states what ARIN does, whereas number resource policy defines the rules for "how" we do it. The update to the mission statement was actually trying to make this very point more clear, i.e. ARIN (the organization) facilitates development of the policy _by the community_. > I disagree and maybe we agree that we disagree here, but this is at the heart of what I think has been wrong with policy making. Assuming by greenfield space you mean that there were plenty of IPv4 addresses available then, I don't see any reason why the depletion of IPv4 should change ARIN's Mission or change ARIN's primary mission to Allocate. ARIN's mission, from day one has included both management and allocation of number resources - refer the NSF's press release re ARIN's formation which states as much > I think the previous Mission Statement is elegant and was constructed very well. Reading it now I think it still does an excellent job of describing ARIN's mission today. A simple change to it to add that the scope that ARIN is now focused on Internet resources in this geographical region is all it needs to be current. Maybe we agree to disagree here too, but I think the new Mission Statement does change the mission. WORDS ARE A POWERFUL THING. We do indeed disagree. Actual community-developed policy for number resource management with should not be pre-empted by"implied" number resource policy that you perceive to be in the mission statement... Note that there are actual Principles of Internet Number Resource Policy" that are beyond the communities ability to directly change - these are actually in the Policy Development Process, Part 1, Section 4 - " 4. Principles of Internet Number Resource Policy Internet number resource policy must satisfy three important principles, specifically: 1) enabling fair and impartial number resource administration, 2) technically sound (providing for uniqueness and usability of number resources), and 3) supported by the community. 4.1. Enabling Fair and Impartial Number Resource Administration Internet number resources must be managed with appropriate stewardship and care. ... " These principles have been affirmed by the ARIN Board of Trustees (after a multiple year update process, including several rounds of community comment) as being an inherent part of Policy Development Process. The ARIN AC is responsible for assessing proposed changes to policy against these principles. > I think the second most important change to the Mission Statement is the removal of the word "stewardship" so I agree with you on that completely! There has been comments in this community about stewardship in a current policy proposal in the last week - but with that word specifically removed from the new Mission Statement - maybe we should no longer be discussing that. (I think we should be discussing stewardship by the way but now our mission is different here.) While the concept of stewardship is well-understood (i.e. the careful management of a resource on behalf of another), the determination of what exactly constitutes good stewardship of number resources is best left to community-developed policy. Whether the phrase is included in the mission statement (or not) does not clarify whether a particular proposed policy change is good stewardship, that ultimately is for the community to decide. If you believe that a proposed policy change would be contrary to good stewardship, please point that out on this mailing list for the AC to include in their assessment. > It's not too late for ARIN to submit the current Mission Statement to this community for input. Counting you Owen, there are at least two of us in this community that would have liked to have some input. Are you listening John? "Are you listening John?" Always. Please submit any suggestions for improvement to the Mission Statement to the ARIN Consultation and Suggestion Process These will be periodically reviewed by ARIN staff, and brought to the ARIN Board for consideration for update to the mission statement (something we should not be doing very often.) Note that we presently have one suggestion already for changing the mission statement Comments from the community on suggestions may be submitted on the arin-consult mailing list, which is open to the public. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Thu Jul 18 10:58:01 2013 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jul 2013 10:58:01 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> Message-ID: On Thu, Jul 18, 2013 at 4:36 AM, David Huberman wrote: > - A section on obtaining additional blocks, which still outlines the 80% rule. > > - We would have to figure out what to do with the requirement to SWIP, > as the requirement is predicated on the classification of "ISP" actually > existing (which it would not). That might need a working group to reconcile. Hi David, If you want to get there incrementally (which IMHO is the only way you might get there), start here. Convert the ISP and end-user specific reporting requirements into address use classes which apply across both registrant types. Start that effort by enumerating the different ways in which addresses are used. Then match them up to what kind of reporting we expect for those uses and why we want that reporting. Examples: Use type: assignment to a customer Desired reporting: SWIP or RWHOIS of address range matched to customer identity Rationale: transparency and accountability. Use type: employee DHCP pool Desired reporting: host count Rationale: We don't need more than a rough host count to evaluate whether you're making efficient use of IP addresses. We know how big your company is so we'll know if your host count is unreasonable. Which employees, which company location, we don't need to know that to authenticate the use. Use type: ephemeral customer pool Desired reporting: 95th percentile use Rationale: We don't need to know each customer temporarily holding an IP address but it's important that you not overfill your DHCP pools while someone else starves for addresses. Some of you have allowed vendors to saddle you with tech that manages addresses badly. This is not OK. Use type: long hold customer pool Desired reporting: If the customer holds the same DHCP address for a year, is there a difference between that and explicitly assigning the address? etc. etc. Next step after that is to merge these use types into general categories based on the desired reporting. Then apply to both types of organizations (ISP and end-user) and retire the org type specific requirements. With reporting equalized, the next step is to equalize the qualification criteria based on the reporting. Once qualifications and reporting are equalized, it falls on the ARIN board to equalize the fee schedule. And then finally we do away with the distinction between ISP and end-user altogether. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Matthew.Wilder at telus.com Thu Jul 18 12:16:34 2013 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Thu, 18 Jul 2013 10:16:34 -0600 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> Message-ID: Hi David, I think this is a great way of looking at. NRPM could be so much simpler, but in a multi-stakeholder world, we all see the tendency for policy changes to complicate, not simplify NRPM. The only way to simplify NRPM to a reasonable (sane) state is to start with a blank sheet of paper, as you say. Our current NRPM is just shy of 15,000 words. The sections which really need to be updated to accomplish your stated objective are section 4 and section 6, which combined contain 8,356 words. In my mind a sane NRPM would have half that many words. If you constrain the efforts simply to merging any policy which distinguishes between End Users and ISPs, you will have around 4,000 words in scope. I imagine the majority of challenge faced in this activity will be merging section 4.2 with 4.3, with several topics sure to create quite the discussion (3 month allocations for ISPs vs 12 months for End Users, Registration for downstream customers to name two). The way I could imagine finding some success in the overarching ambitions is to define what sections of NRPM we are interested in transforming, and by contrast those which we believe should stand. I believe that the majority of content outside section 4 and section 6 is reasonable enough. I also believe that your intent is primarily to simplify the NRPM as it relates to allocation of IPv4 and IPv6 resources, so likely the energy should naturally focus on those 2 sections. If the community is in support of re-writing those sections of NRPM, the two following topics should be considered for discussion (and possibly more I have not identified): 1. Will three month allocations apply also to End-Users as it does to ISPs? This is going to be the biggest bone of contention as I see it, and the big reason why many would still see value in a distinction between ISP and End-User, despite lines blurring as many have observed. I work for an ISP, and I see the similarities of hotels, coffee shops, CDNs, cloud providers and so on. To what set or subset of Orgs should the three month allocation apply? Merging End-Users and ISPs in policy will be challenging here. 2. What reassignments need to be registered for the global community's benefit in a paradigm which no longer distinguishes between ISP and End-User? I would suggest that static assignments of a certain size to entities outside the Organization specified as the resource holder should be registered. This mean Starbucks and the Hyatt don't have to register their DHCP pools used by their customers (although maybe a record of that DHCP would be desirable). In any case, this needs to be thought through at a higher level and then specifications laid out. I am certainly interested in seeing what other have to say. It may be very difficult to parse what can be reasonably removed from expectations of ISPs in order to align with End-Users, and conversely how happy End-Users will be to share the 3-month allocation policy with ISPs. If the majority of value is seen by many in simple alignment of initial allocation and assignment (and to some degree subsequent allocation / assignment), I believe the policy changes will be much easier to manage and build consensus around. Cheers, Matthew Wilder -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: July 18, 2013 01:36 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Initial ISP Allocation Policy Hello everyone, I would like to thank everyone for a very good discussion in this thread. First I'll give a very brief summary of the discussion so far, and then I have a solution to float to the list for feedback. Myself, Dan, Bill, and Steven have posted in favor of the high level concept that the differentiation in ARIN policy between enterprise networks and provider networks is no longer productive or relevant. Owen may agree in principle, but cautions us to be very careful with how we proceed. He is concerned that an effective "one size fits all" solution may be very difficult to design. George offers us an alternative nomenclature to consider (NSP v. ISP). I would like to now shift the discussion to how we approach potentially collapsing the two categories into one so that future interactions with ARIN are conducted under policy language which is relevant in 2014 and beyond. I agree with Dan that a wholesale paradigm shift in ARIN policy can only be accomplished with multiple proposals. There would be quite a few sections to change (with each change requiring careful consideration by the community). Moreover, I think we must be sensitive to ARIN's need to react to the possible impacts to both the financial and workflow modeling that would result from any changes we propose. At the same time, incremental change in NRPM is actually really hard. If this were 5 years ago, I would probably work very hard to help effect incremental change. But I think ARIN and the community have together failed to react to changes in the market over the last 15 years, and it is time to consider very big change. Let's get NRPM into a sane state for 2014 and beyond. In an effort to roll up sleeves and be productive, please indulge me while I lay out one potential vision for what a sane NRPM might look like. I warn you, good reader, that some of what I propose is very radical. - A section on obtaining initial IPv4 addresses from ARIN. No distinction between end-users and ISPs. No distinction between single-homed and multi-homed deployments (*if you don't understand why the difference has no virtue, ping me on or off list and I will show you the math as I see it). Text might look something like: "In order to receive an initial allocation from ARIN, an organization must: - demonstrate they operate an IP network that requires IPv4 addresses to deploy and/or grow; and - provide a numbering plan detailing how IPv4 addresses will be used in the first 180 days upon receiving an allocation. ARIN will review and verify the data provided, and provide for the organization's 6 month need." - A section on obtaining additional blocks, which still outlines the 80% rule. ("If you've efficiently used what you have, you can have more" is a technically sound concept that does not need much fixing.) Platform differences which are already fleshed out in NRPM (e.g., residential market area provider networks with their different metrics than more common buildouts) can and should remain. - We would have to figure out what to do with the requirement to SWIP, as the requirement is predicated on the classification of "ISP" actually existing (which it would not). That might need a working group to reconcile. - A section on obtaining initial IPv6 addresses from ARIN. Given that IPv6 is still very much in its infancy, I really would like to see very simple NRPM text which allows requestors to self-select what size block they need. The only barrier to abuse or silliness would be the fee schedule. It is arrogant and technically indefensible that ARIN policy today tries to dictate what a network does, and does not, justify as far as block size. IPv6 is much too immature for ARIN policy to presume such wisdom. - A section on obtaining additional IPv6 addresses from ARIN. Existing text in 6.5.3 is probably good enough for today, as there are only a handful of networks in the world with any experience needing additional IPv6 addresses due to efficient use of an initial block. Obtaining additional IPv6 addresses is a topic for many years from now, not today. Do you think any of this has value? Would it accomplish the overarching goal of improving ARIN policy to make it relevant to network operators in 2014 and beyond? What would your sane NRPM look like? With regards, David _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Jul 18 19:04:11 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jul 2013 19:04:11 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013A434C7B@ENI-MAIL.eclipse-networks.com> References: <01f601ce7e73$04068cc0$0c13a640$@tndh.net> <51DF46C3.9020900@umn.edu> <5B9E90747FA29 74D91A54FCFA1B8AD120137D6C71E@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-MAIL.eclipse-networks.com> <4484986C-C756-4922-8E95-BF150757A6E4@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013A434C7B@ENI-MAIL.eclipse-networks.com> Message-ID: Again, to me, what you call "right-sizing" and what I call "needs basis" are identical. The "right sizing" criteria you describe do not materially differ from the needs tests currently applied by ARIN. I've never had ARIN ask me for ARP logs on a request. Generally speaking, from my perspective, the existing forms basically ask what size network do you currently have, what is your projected need for growth, how are you currently utilizing the space you already have, and where do you intend to use the space you have requested. Seems very much the same as what you are suggesting to me. I think that you will find that removing the distinction between end user and ISP will not lead to right-sizing things correctly because the growth rates and types of needs tend to be rather radically different between the more extreme definitions of either case. Admittedly, it gets more grey when we start looking at some of these hybrid organizations (ISPs with virtual hosting, CDNs that also sell transit, etc.) and a unified policy might work well for some of those. Owen Sent from my iPad On Jul 17, 2013, at 11:58 PM, Steven Ryerse wrote: > I don?t view this to be needs based at all, I view it to be a way to right size allocations without the needs tests. For example nowhere does it ask for router ARP logs or any other form of proof of need nor does it ask how long it will take to use up the allocation. It just asks what size network are you now with size of org thrown in for larger allocation requests. It also empowers ARIN management to consider unusual situations and allows ARIN to give a positive allocation if ARIN deems it reasonable after discussion. It simplifies a lot and could replace several policies. It removes the need to even define which org is an end user and which org is an ISP. It levels the playing field which in my opinion needs to be done. I think this is pretty far from the current allocation policies. This is a simple way to accomplish what has been proposed for RIPE to remove all of the needs test from their policies. Simple is good and simple is fair. > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, July 17, 2013 4:21 PM > To: Steven Ryerse > Cc: Blake Dunlap; arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > You've just described pretty much what happens now. This is, to me at least, indistinguishable other than a few subtle operational details from the current needs-basis policy and process(es). > > Owen > > On Jul 15, 2013, at 3:53 PM, Steven Ryerse wrote: > > > If you are publicly traded and your company?s revenues are public then the size of the company is available to all. This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large block size. The other info that could be used is how much resource does an org have now. If they have a /8 they might really have use for another /8. If they have a /22 they might really have use for another /22. Obviously the org with a /22 isn?t likely to have use for a /8. Orgs with multiple allocations already can add them together including legacy blocks. An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 . The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting ? I?m thinking this would require a manager at ARIN to handle. I?m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required. In this way the blocks allocated are right sized for the size of the org requesting the allocation. There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: Blake Dunlap [mailto:ikiris at gmail.com] > Sent: Monday, July 15, 2013 3:01 PM > To: Steven Ryerse > Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > Exactly how is this "right sized allocation" based on network size different than needs basis allocation? > > -Blake > > > On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse wrote: > Note that I did say "right sized allocations" and have said multiple times that it is fine to match allocations with the size of the organization and/or the size of the organization's current network. I also have stated that we need to be good technical stewards and I think most folks here agree with that. I do not think a small organization like ours for example should ever get the technical equivalent of a /8 or even close to it. I do strongly think that every organization should be able to get a right sized allocation if they are going to use it as that grows the Internet - which in case folks forget is ARIN's mission. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: Matthew Wilder [mailto:Matthew.Wilder at telus.com] > Sent: Friday, July 12, 2013 12:18 PM > To: Steven Ryerse; David Farmer > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore. > > To be clear, IP Address schemes can only be updated so far. As far as I can tell IPv4 address schemes have never extended beyond the initial 32 bits they started off with, and IPv6 also will not change from a 128 bit address length. Granted, CIDR was introduced to IPv4 to extend the timeline for exhaust of IPv4 address resources, but this is exceptional, and not the rule (certainly for the future). > > And the cost you mention is not a negligible one. Think of the amount of time and energy that has already gone into IPv6 only to approach 2% of global IP traffic on IPv6. I believe it is in the community's best interest to conserve the word conservation in some form. As David said, the conservation of IPv6 resources is going to be much different than conservation of IPv4 resources. > > By the way, for those not following, there is a push from many member nations of the ITU and others in the international community to redistribute the governance of the internet in their interests. Do not be surprised if the nations gain the ability to allocate IP Address resources to the entities within their borders. In that world, IPv6 exhaust is only a short matter of time. If we can at least embed the concept of conservation of IPv6 resources now in some way, the global community will thank us a generation or two from now. > > mw > > On July 12, 2013 at 08:50 AM, "Steven Ryerse" wrote: > > > I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all - we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them. > > > > Bill is right that the word conserve needs to be removed. > > > Sent from my iPhone > > > On Jul 11, 2013, at 7:59 PM, "David Farmer" wrote: > > > > I really don't understand this debate on Conservation. :{ > > > > > > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out. > > > > > > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water." > > > > > > Then others are not willing to concede that anything changes with IPv4 run-out. > > > > > > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a network should be able to get unique addresses), etc... > > > > > > So how do we move forward? I suggest; > > > > > > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either. > > > > > > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues. > > > > > > 3. Are there other concepts, principles, or goals that were missing? > > > I suggested earlier that there were additional principles we should > > > be looking at. An candidates has come up in the conversation today > > > that I would like to propose; > > > > > > 0.2 Fair Distribution > > > > > > The principle of Fair Distribution is the precept that the > > > fundamental purpose of Internet number resources management is to > > > distributed unique number resources in a fair and impartial manner > > > to entities building and operating networks, for benefit of all > > > Internet users equally, and thereby facilitating the growth and > > > sustainability of the Internet. > > > > > > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability" > > > > > > Thanks > > > -- > > > ================================================ > > > David Farmer Email: farmer at umn.edu > > > Office of Information Technology > > > University of Minnesota > > > 2218 University Ave SE Phone: 1-612-626-0815 > > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > > ================================================ > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jul 18 19:28:27 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jul 2013 19:28:27 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013A434F32@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@ENI-M > <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli > <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <5B9 E90747FA2974D91A54FCFA1B8AD120137D6F296@ENI-MAIL.eclipse-networks.com> <51E4 80E0.7070606@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com> <39D8D428-269E-469A-859C-5CF27B5A5EC9@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013! !A431454@ENI-MAIL.eclipse-networks.com> <57519C53-DECC-4956-B1E1-025E1DA5538A@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013A434F32@ENI-MAIL.eclipse-networks.com> Message-ID: <53AD8BD7-DF8E-46EF-9857-465213D09B2B@delong.com> Sent from my iPad On Jul 18, 2013, at 1:23 AM, Steven Ryerse wrote: > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, July 17, 2013 8:50 PM > To: Steven Ryerse > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised > > > On Jul 17, 2013, at 5:30 PM, Steven Ryerse wrote: > >> Correct, the Missions Statement isn't policy but policies all need to flow from and be in alignment with the Mission Statement. It exists to help guide ARIN and this community in day to day matters. I don't know who wrote the original Mission Statement - maybe IANA and NSF and others were involved - I don't know for sure. > >>> You made the statement that the BoT changing the mission statement without community input was not in line with the claim that policies are developed by the community. I was pointing out the fallacy in that argument by pointing out that the mission statement was not policy. Policies are developed by the community. Other things about ARIN are not. At least not directly. > > I would say that if something big is contemplated such as a Mission Change, which is what I believe this new Mission Statement is, why would ARIN not automatically solicit input on a proposed Mission Statement change from this community? John has said many times including under oath that ARIN implements policies that this community wants. If ARIN changes the Mission Statement without soliciting input from this community on the proposed changes, then in my opinion ARIN is not honoring the spirit of their long standing commitment to include this community in policy decisions - since all policies should flow from and be aligned with the Mission Statement. As I said, I do not think that anyone involved in the change thought it was a change in mission at the time. The feeling was that it was an update to the text in order to make it more accurately reflect the actual mission. Whether they were correct in that belief or not (I believe they were, but obviously you feel differently), I think it was done in good faith believing that it was a text cleanup and not an actual change to the mission. Indeed, if you look at the dates on NRPM section 8, it is clear that ARIN has been doing more than allocating resources and has been, in fact, more accurately managing them rather than merely allocating them for many years. As such, I would argue that managing was always their mission and that allocate was, at one time, the majority of managing to a sufficient extent that nobody recognized the distinction at the time of writing the original mission statement. I challenge you to point to a time in history when ARIN's exclusive mission was actually allocation in terms of their policies and/or their actual practices. I do not believe such a time exists. I think that John has already stated that the board will exercise greater care in the future when updating the mission statement. Given that this is the first update in 12 years to the best of my recollection, I doubt that the issue is all that likely to come up again soon anyway. If you feel that there are other ways in which the new mission statement represents a change in mission, please elaborate. Otherwise, I think this discussion has run its course and we can agree to disagree about whether the changes to the mission statement were a change in mission or whether they were a textual update to more accurately reflect the long standing and existing mission. >> In my opinion these are very different. The first says ARIN is to allocate, and the second says ARIN only has to manage - and thus doesn't necessarily have to allocate. > >>> At the time ARIN was created, managing internet resources consisted almost exclusively of the process of allocating resources from greenfield space. Things have changed since then. We now have transfers of IPv4 resources and ASNs, reclaimed and returned resources (to a much greater degree than when ARIN was created), inter-regional transactions, etc. As such, I think that the term manage has become more consistent with ARIN's current mission whereas allocate describes only a subset. > > I disagree and maybe we agree that we disagree here, but this is at the heart of what I think has been wrong with policy making. Assuming by greenfield space you mean that there were plenty of IPv4 addresses available then, I don't see any reason why the depletion of IPv4 should change ARIN's Mission or change ARIN's primary mission to Allocate. I know others might disagree but I strongly believe this. Certainly the stewardship portion of the previous Mission Statement should be applied - and that stewardship function should make sure allocations were/are not made willy nilly, but I believe the stewardship responsibility wasn't meant to be used to NOT allocate ; or maybe somehow make sure that an allocation is used up in a certain amount of time or whatever. This is why I have recently proposed to right size allocations (and remove needs based tests) and then get the allocations out there to orgs that will use them - which by the way fulfills the "advancement of the Internet" portion of the previous Mission Statement. Do you feel that ARIN should not process transfers of number resources? Do you feel that ARIN should not perform RPKI resource verification? Do you feel that ARIN should not maintain the whois database and process updates? Do you feel that ARIN should not accept returned resources from people who no longer need them? Do you feel that any of the above items are new parts of ARIN's mission? Arguably, RPKI, since it is new is a new part, but otherwise, I believe ARIN has performed each and every one of these non-allocation management functions since its inception. If you truly feel that ARIN should not perform those functions, then we are very far apart and should agree to disagree. If you feel that ARIN should perform those functions, then I submit that ARIN is, in fact, supposed to manage the address space (that's management, afterall) and not merely allocate it. > >> I have no way of knowing but I wonder if IANA is OK with a change like this. Would they need to approve of a significant Mission Statement change for an RIR? I don't know how that all works. > >>> Well, per the MoU, IANA policies (with respect to number resources) are governed by policies which achieve consensus through the independent policy development process in all 5 RIRs and are then ratified by the NRO NC and subsequently ratified by the ICANN Board. As such, I can't see how IANA could object to a change like this since IANA has no role in defining the policies of the RIRs, but, rather operates in the other direction? The collective RIRs through the NRO manage the IANA policies. > >> I have many times pointed out in this community that a particular policy or policy proposal does/did not match the Missions Statement. I guess instead of working with this community to align policies with the Mission Statement, ARIN decided to make the Missions Statement fit the policies. > >>> I think, rather, that the original mission statement was an artifact of the time when it was created and we live in a different time now. I do not believe that the change in the mission statement represents a change in mission or an adaptation of the mission statement to fit the policies nearly so much as it represents a change in wording to recognize the larger nature of the mission than was evident at the time of ARIN creation. > > I think the previous Mission Statement is elegant and was constructed very well. Reading it now I think it still does an excellent job of describing ARIN's mission today. A simple change to it to add that the scope that ARIN is now focused on Internet resources in this geographical region is all it needs to be current. Maybe we agree to disagree here too, but I think the new Mission Statement does change the mission. WORDS ARE A POWERFUL THING. I utterly disagree. First, the original mission statement claims that ARIN sets the policies. It does not reflect that the community drives the policy process. In fact, that issue was the main reason motivating the board to correct it. I do think that the loss of the words "Applying the principles of stewardship" was unfortunate, but not all that significant. Otherwise, I feel that the current mission statement is a vast improvement over the previous one and does a much better job of accurately reflecting ARIN's mission as it has always been. > >>> If ARIN's sole responsibility is to allocate, then who should process reclamations, returns, transfers, and other aspects of management of the address space? How do you see such a structure working? > > I only mentioned previously what I think is the most important change, and that is the allocation verbiage has been removed. I think the word "protocol" could be removed from the previous Mission Statement and it would include all that you list below. I think all portions of the previous Mission Statement are important and should be retained. If you allocate and do not manage, then you can't do anything but one-way hand-it-out. You can't process updates to whois. You can't process transfers. You can't accept returns or make reclamations, etc. All of those are functions of management that are not allocation. >> As I said ARIN does have the right to change it without this >> community's input but it sure leaves a bad taste in my mouth for ARIN >> not to have sought this community's input on something as significant >> as a Mission Statement rewrite. In my humble opinion it feels like >> they went behind my (our?) back and deprived this community of the >> much needed opportunity to truly debate and have input to what we want >> the overall mission of ARIN to be. Just my two cents. :-( > >>> It left a bad taste in my mouth as well. I informed several board members of that fact at the time. > >>> I don't think that it was their intent to go behind anyone's back. Indeed, I think it was out-of-control group-think on the word smithing when they set out to clarify that the policies are, in fact, set by the community. Having talked to most of the people responsible for the change, I don't believe that any of them felt that the change was meaningful beyond the clarification intended. > >>> I was actually more upset about the loss of the "principles of stewardship" at the time. I still don't see the change from allocate to manage as being a material change to the mission statement (or to the mission) so much as a recognition of the current reality. > > I think the second most important change to the Mission Statement is the removal of the word "stewardship" so I agree with you on that completely! There has been comments in this community about stewardship in a current policy proposal in the last week - but with that word specifically removed from the new Mission Statement - maybe we should no longer be discussing that. (I think we should be discussing stewardship by the way but now our mission is different here.) In discussing it with the board, the members I talked to actually said that the removal of the word was not particularly deliberate, just an oversight in the word smithing process. As such, I think that continuing to discuss stewardship is perfectly appropriate. > It's not too late for ARIN to submit the current Mission Statement to this community for input. Counting you Owen, there are at least two of us in this community that would have liked to have some input. Are you listening John? Perhaps. As I said, it annoyed me at the time, but I don't find sufficient fault with the current mission statement to feel that it is worth all that much effort. If you do, there is always the ACSP where you can formally suggest that such a review by the community be opened. Owen From mysidia at gmail.com Thu Jul 18 20:14:41 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 18 Jul 2013 19:14:41 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: References: <51966083.2010003@arin.net> <51DB3076.5080304@arin.net> Message-ID: On 7/15/13, Jason Schiller wrote: > Jimmy, > This proposal is an attempt to collect these principles in one coherent > place, and not loose the text when the original RFC2050 is deprecated. > This is the only goal of this proposal. May I remind you.. that deprecation of an RFC for IETF purposes does not make the text "no longer available" --- it is not as if deprecated RFCs get deleted. It does not necessarily mean the document is suddenly useless or invalid for other purposes, either. > It is not intended to be policy, but rather is text that has guided policy > development and it is hoped will be used to continue to guide policy > development. There is a process laid out in the PDP for NRPM changes that are not policy. "Changes to policy that are purely editorial and non-substantial in nature are outside the scope of the full Policy Development Process and may only be made with 30 days public notice followed by the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees that the changes are non-substantial in nature." > It has been suggested by many that an RFC is not the right place to > record these principles as they are not prescriptions that the IETF > places on the RIRs. That is true, but the meaningful policy implications have not been explained. > So that left placing these principles in the NRPM. A place that the > community looks after and can easily change. If the community can easily change them, then they are not really principles. The principles are the things you have to agree on, before you even start developing policy; they essentially never change, except in a major turn of events that turn the RIRs into different kind of organizations. > No. We have a suggestion that the community should carefully balance > these principles an use that to guide them in forming actual policy. Then we have an invalid policy assertion proposed to be in the PPML; the PPML itself doesn't get to say how policy is developed, or what the community does in making changes to policy --- that is self-referential. The PPML is number resource policy, not policy making policy. > __Jason -- -JH From owen at delong.com Thu Jul 18 23:59:13 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jul 2013 23:59:13 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: Sent from my iPad On Jul 18, 2013, at 1:13 AM, William Herrin wrote: > On Wed, Jul 17, 2013 at 8:54 PM, Owen DeLong wrote: >> On Jul 17, 2013, at 5:00 PM, William Herrin wrote: >>> On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: >>>> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >>>>> What about Comcast? They're in the business of providing cable >>>>> television service. They'll also provide you with Internet access on >>>>> the same coax cable with the modem they rent you. >>>>> >>>>> ISP or end-user? >>>> >>>> The service is intended to be used to connect customer-owned >>>> equipment to the internet. As such, they are clearly in the LIR/ISP realm. >>> >>> Starbucks, Hilton, they have large sections of the operation dedicated >>> to connecting customer-owned equipment to the Internet. >> >> Permit me to rephrase? The service (in the case of Comcast) is >> intended to connect customer-owned networking equipment to the >> internet (e.g. routers, bridges, etc.). In the case of Starbucks, >> Hilton, etc., the expectation is that you are connecting a terminal >> host and not a packet forwarding device. > > Huh? Comcast is an ISP because they give you a modem to connect > between the coax and your ethernet port but Starbucks isn't because > you connect to a wifi access point instead? > Comcast expects most of their customers to be attaching routers, not computers to the modem. Starbucks does NOT expect you to be associating a router with their wifi. I thought I was pretty clear about that above, but perhaps you have trouble understanding the distinction I am drawing between packet forwarding equipment and packet terminating hosts. I thought I was clear, I apologize if I was not. >> I think getting into this level of semantic detail is a clear case of reductio ad absurdum. > > I'll say it is! You went there. > The point here is that 21st century networks don't look like the > dialup+webhost ISP of 1997, nor do they look like the "our employees > have Netscape and Eudora" end-user of 1997. Attempts to shoehorn 21st > century networks into those obsolete definitions frankly come up > looking pretty stupid. That doesn't mean that one size fits all, either. > What we *do* see is organizations managing IP addresses in several ways: > > 1. assigned to organization-owned infrastructure under the control of > the organization's employees End-user. > 2. assigned long-term to exclusive use by the organization's customers or users LIR/ISP in most cases. > 3. ephemerally assigned to exclusive use by the organization's > customers or users Could go either way, but most likely LIR/ISP if customers and End-user if users. > 4. reserved for future use Not sure what this means in this context, so very hard to make a meaningful reply. > And we see that most organizations do a mix of all of these things, > not one or the other. Actually, I would say that most organizations fit into 1 or 2 pretty readily most of the time and we are seeing a growing, but still small number of corner cases that are more difficult to classify. Nonetheless, treating all organizations the same would definitely be either grossly unfair to those in category 1, grossly unfair to those in category 2, or both IMHO. Owen From owen at delong.com Fri Jul 19 00:23:29 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Jul 2013 00:23:29 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> Message-ID: <74008122-7E64-423E-96D6-EEFA8FC3DE47@delong.com> Sent from my iPad On Jul 18, 2013, at 4:36 AM, David Huberman wrote: > Hello everyone, > > I would like to thank everyone for a very good discussion in this thread. First I'll give a very brief summary of the discussion so far, and then I have a solution to float to the list for feedback. > > Myself, Dan, Bill, and Steven have posted in favor of the high level concept that the differentiation in ARIN policy between enterprise networks and provider networks is no longer productive or relevant. Owen may agree in principle, but cautions us to be very careful with how we proceed. He is concerned that an effective "one size fits all" solution may be very difficult to design. George offers us an alternative nomenclature to consider (NSP v. ISP). > > I would like to now shift the discussion to how we approach potentially collapsing the two categories into one so that future interactions with ARIN are conducted under policy language which is relevant in 2014 and beyond. > > I agree with Dan that a wholesale paradigm shift in ARIN policy can only be accomplished with multiple proposals. There would be quite a few sections to change (with each change requiring careful consideration by the community). Moreover, I think we must be sensitive to ARIN's need to react to the possible impacts to both the financial and workflow modeling that would result from any changes we propose. > > At the same time, incremental change in NRPM is actually really hard. If this were 5 years ago, I would probably work very hard to help effect incremental change. But I think ARIN and the community have together failed to react to changes in the market over the last 15 years, and it is time to consider very big change. Let's get NRPM into a sane state for 2014 and beyond. > > In an effort to roll up sleeves and be productive, please indulge me while I lay out one potential vision for what a sane NRPM might look like. I warn you, good reader, that some of what I propose is very radical. > > - A section on obtaining initial IPv4 addresses from ARIN. No distinction between end-users and ISPs. No distinction between single-homed and multi-homed deployments (*if you don't understand why the difference has no virtue, ping me on or off list and I will show you the math as I see it). Text might look something like: > > "In order to receive an initial allocation from ARIN, an organization must: > > - demonstrate they operate an IP network that requires > IPv4 addresses to deploy and/or grow; and > > - provide a numbering plan detailing how IPv4 addresses > will be used in the first 180 days upon receiving an allocation. > > ARIN will review and verify the data provided, and provide for the organization's 6 month need." > 6 months is far too short a planning horizon for any organization, IMHO. The intent of the (now ridiculous) 3 month window in the ISP policy was to make sure that the 1 year request at the head of the line could not drain the pool granting $ISP-A a 1-year advantage over everyone else in line ($ISP-B through $ISP-Z, for example). I think that the 1 year time horizon for IPv4 is still perfectly reasonable so long as there is an IPv4 free pool. I think that having a dichotomy between the transfer planning horizon and the free-pool planning horizon is utterly and completely harmful and I will continue to argue against that. > - A section on obtaining additional blocks, which still outlines the 80% rule. ("If you've efficiently used what you have, you can have more" is a technically sound concept that does not need much fixing.) Platform differences which are already fleshed out in NRPM (e.g., residential market area provider networks with their different metrics than more common buildouts) can and should remain. Admittedly, this may be within your IPv4 policy in which case it makes sense, but since you said additional blocks and not additional IPv4 blocks, I have to point say I think this is a very silly way to approach IPv6, especially for service providers. First, I think that the current iPv6 policy is much more liberal and does a much better job of allowing for organic asymmetric growth as is more likely to occur than symmetric growth required by a straight 80% rule which has always been problematic. It was a reasonable compromise to deal with scarcity, but it would be very harmful IMHO for IPv6. > - We would have to figure out what to do with the requirement to SWIP, as the requirement is predicated on the classification of "ISP" actually existing (which it would not). That might need a working group to reconcile. You've just punted on one of the central reasons for the distinction. This is a classic example of where the devil is in the details and you've chosen a hand-wave over the details. I don't mean to be flip or glib, but if you don't have a solution here, then you have a building with no foundation, IMHO. > - A section on obtaining initial IPv6 addresses from ARIN. Given that IPv6 is still very much in its infancy, I really would like to see very simple NRPM text which allows requestors to self-select what size block they need. The only barrier to abuse or silliness would be the fee schedule. It is arrogant and technically indefensible that ARIN policy today tries to dictate what a network does, and does not, justify as far as block size. IPv6 is much too immature for ARIN policy to presume such wisdom. I very much disagree with you here. The present IPv6 policy comes up very close to what you propose and does virtually allow an organization to self-select any remotely-conceivable block size that they need. The formula in current ISP policy allows so much round-up of ones most optimistic projections of ones largest pieces of their network that it is very easy to get a quite large block of IPv6 addresses. I have worked on two applications for /24s under the current policy that were successful. The first one (a subsequent allocation for an ISP that already had a /32) was very easy. The second one took a little more effort to convince ARIN that the organization in question truly operated as an ISP, but once ARIN was convinced that they were an ISP and not an end-user (the confusion was actually quite understandable in this particular case), it also sailed through. In neither case were there any significant hurdles in terms of the size of request. As to the end user policy, it's pretty easy now. Admittedly, you either have to be sizeable or multi-homed, but I don't think that's related to the ISP/End-User distinction nearly so much as it is an artifact of the portion of the community that is hyper-concerned with routing-table growth. While I agree with you that it would be desirable to remove the multihome constraint from policy, such a move has not yet achieved community consensus. That would be an improvement to existing policy, IMHO. Beyond that, the end-user policy boils down to: Count the number of end sites you have. Round up to a nibble boundary and move left from /48. So you get at least one /48 per end-site. Since an end-site is defined as a single building or structure or a single tenant in a multi-tenant building or structure, I think that's a pretty reasonable starting point. However, the policy also includes a relief valve just in case that allows you to request multiple /48s for any end-site that needs more than 40,000 (IIRC) unique networks. I think that having a different formula for those allocating addresses to others and those directly managing end sites makes a lot of sense as the required management regimes are quite different in my experience. I admit that if you just let everyone choose their block size based on how much they want to pay, this distinction loses a lot of relevance, but I don't think that such a policy is in any way a positive change at this time. I think it would amount to turning ARIN into an IPv6 auction house offering address space to the highest bidders, thus allowing wealthy corporations to get whatever they needed while likely increasing the pricing for many end-users for even just a /48 to the point that they could no longer retain their blocks. > - A section on obtaining additional IPv6 addresses from ARIN. Existing text in 6.5.3 is probably good enough for today, as there are only a handful of networks in the world with any experience needing additional IPv6 addresses due to efficient use of an initial block. Obtaining additional IPv6 addresses is a topic for many years from now, not today. Not necessarily so many years as you may think given the number of thoroughly undersized allocations that are still out there. > Do you think any of this has value? Would it accomplish the overarching goal of improving ARIN policy to make it relevant to network operators in 2014 and beyond? What would your sane NRPM look like? I'm very skeptical for the reasons outlined above. I applaud your effort, but I could not support such a policy. Owen From narten at us.ibm.com Fri Jul 19 00:53:03 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 19 Jul 2013 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201307190453.r6J4r3YK026311@rotala.raleigh.ibm.com> Total of 80 messages in the last 7 days. script run at: Fri Jul 19 00:53:03 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.00% | 12 | 27.24% | 287028 | sryerse at eclipse-networks.com 20.00% | 16 | 20.50% | 215940 | owen at delong.com 15.00% | 12 | 7.99% | 84146 | bill at herrin.us 6.25% | 5 | 7.11% | 74903 | jschiller at google.com 6.25% | 5 | 5.87% | 61808 | matthew.wilder at telus.com 5.00% | 4 | 7.08% | 74616 | cgrundemann at gmail.com 6.25% | 5 | 4.56% | 48067 | farmer at umn.edu 6.25% | 5 | 3.83% | 40378 | jcurran at arin.net 2.50% | 2 | 3.48% | 36650 | david.huberman at microsoft.com 2.50% | 2 | 1.83% | 19259 | daniel_alexander at cable.comcast.com 2.50% | 2 | 1.34% | 14113 | mysidia at gmail.com 2.50% | 2 | 1.31% | 13830 | mueller at syr.edu 1.25% | 1 | 2.24% | 23563 | ikiris at gmail.com 1.25% | 1 | 1.08% | 11377 | george.herbert at gmail.com 1.25% | 1 | 1.00% | 10573 | dave at temk.in 1.25% | 1 | 0.95% | 9993 | jdaniels at forked.net 1.25% | 1 | 0.90% | 9446 | jkrejci at usinternet.com 1.25% | 1 | 0.67% | 7035 | narten at us.ibm.com 1.25% | 1 | 0.54% | 5661 | gary.buhrmaster at gmail.com 1.25% | 1 | 0.50% | 5229 | kkargel at polartel.com --------+------+--------+----------+------------------------ 100.00% | 80 |100.00% | 1053615 | Total From bjones at vt.edu Fri Jul 19 09:12:19 2013 From: bjones at vt.edu (Brian Jones) Date: Fri, 19 Jul 2013 09:12:19 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> <5735ad420e61414ab5c8eb936c930900@BN1PR03MB250.namprd03.prod.outlook.com> Message-ID: See inline comments. -- Brian On Thu, Jul 18, 2013 at 4:36 AM, David Huberman < David.Huberman at microsoft.com> wrote: > Hello everyone, > > I would like to thank everyone for a very good discussion in this thread. > First I'll give a very brief summary of the discussion so far, and then I > have a solution to float to the list for feedback. > > Myself, Dan, Bill, and Steven have posted in favor of the high level > concept that the differentiation in ARIN policy between enterprise networks > and provider networks is no longer productive or relevant. Owen may agree > in principle, but cautions us to be very careful with how we proceed. He > is concerned that an effective "one size fits all" solution may be very > difficult to design. George offers us an alternative nomenclature to > consider (NSP v. ISP). > > I would like to now shift the discussion to how we approach potentially > collapsing the two categories into one so that future interactions with > ARIN are conducted under policy language which is relevant in 2014 and > beyond. > > I agree with Dan that a wholesale paradigm shift in ARIN policy can only > be accomplished with multiple proposals. There would be quite a few > sections to change (with each change requiring careful consideration by the > community). Moreover, I think we must be sensitive to ARIN's need to react > to the possible impacts to both the financial and workflow modeling that > would result from any changes we propose. > > At the same time, incremental change in NRPM is actually really hard. If > this were 5 years ago, I would probably work very hard to help effect > incremental change. But I think ARIN and the community have together > failed to react to changes in the market over the last 15 years, and it is > time to consider very big change. Let's get NRPM into a sane state for 2014 > and beyond. > > In an effort to roll up sleeves and be productive, please indulge me while > I lay out one potential vision for what a sane NRPM might look like. I > warn you, good reader, that some of what I propose is very radical. > > - A section on obtaining initial IPv4 addresses from ARIN. No distinction > between end-users and ISPs. No distinction between single-homed and > multi-homed deployments (*if you don't understand why the difference has no > virtue, ping me on or off list and I will show you the math as I see it). > Text might look something like: > > "In order to receive an initial allocation from ARIN, an > organization must: > > - demonstrate they operate an IP network that requires > IPv4 addresses to deploy and/or grow; and > > - provide a numbering plan detailing how IPv4 addresses > will be used in the first 180 days upon receiving an > allocation. > > ARIN will review and verify the data provided, and provide for the > organization's 6 month need." > > - A section on obtaining additional blocks, which still outlines the 80% > rule. ("If you've efficiently used what you have, you can have more" is a > technically sound concept that does not need much fixing.) Platform > differences which are already fleshed out in NRPM (e.g., residential market > area provider networks with their different metrics than more common > buildouts) can and should remain. > The 80% rule may not be appropriate in the IPv6 realm. I would argue that the percentage should be less for IPv6 additional requests. > > - We would have to figure out what to do with the requirement to SWIP, as > the requirement is predicated on the classification of "ISP" actually > existing (which it would not). That might need a working group to > reconcile. > > - A section on obtaining initial IPv6 addresses from ARIN. Given that IPv6 > is still very much in its infancy, I really would like to see very simple > NRPM text which allows requestors to self-select what size block they need. > The only barrier to abuse or silliness would be the fee schedule. It is > arrogant and technically indefensible that ARIN policy today tries to > dictate what a network does, and does not, justify as far as block size. > IPv6 is much too immature for ARIN policy to presume such wisdom. > I do not agree that IPv6 is "very much in its infancy" or "immature". We have had IPv6 deployed in some form since 1997. Any forward thinking R&E should already be there. By those standards IPv4 was immature back in the late 1980's, but that sure didn't stop an Internet explosion. Fee schedules should not be implemented in any way that will prohibit IPv6 adoption. In other words blocks of IPv6 addresses should remain relatively easy to justify the need for. > > - A section on obtaining additional IPv6 addresses from ARIN. Existing > text in 6.5.3 is probably good enough for today, as there are only a > handful of networks in the world with any experience needing additional > IPv6 addresses due to efficient use of an initial block. Obtaining > additional IPv6 addresses is a topic for many years from now, not today. > I think there are already organizations requesting additional allocations of IPv6 addresses. Don't shove it under the rug and pretend its not an issue. Better to figure it out ahead of the growth curve. > Do you think any of this has value? Would it accomplish the overarching > goal of improving ARIN policy to make it relevant to network operators in > 2014 and beyond? What would your sane NRPM look like? > > With regards, > David > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel_Alexander at Cable.Comcast.com Fri Jul 19 09:57:15 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 19 Jul 2013 13:57:15 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: Message-ID: Owen, I don't think you work for Comcast or Starbucks, so speaking for them as to what they expect is incorrect. I do work for one of them and cannot speak for what they expect. -Dan Alexander Speaking only for myself and not representing my employer On 7/18/13 11:59 PM, "Owen DeLong" wrote: > > >Sent from my iPad > >On Jul 18, 2013, at 1:13 AM, William Herrin wrote: > >> On Wed, Jul 17, 2013 at 8:54 PM, Owen DeLong wrote: >>> On Jul 17, 2013, at 5:00 PM, William Herrin wrote: >>>> On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: >>>>> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >>>>>> What about Comcast? They're in the business of providing cable >>>>>> television service. They'll also provide you with Internet access on >>>>>> the same coax cable with the modem they rent you. >>>>>> >>>>>> ISP or end-user? >>>>> >>>>> The service is intended to be used to connect customer-owned >>>>> equipment to the internet. As such, they are clearly in the LIR/ISP >>>>>realm. >>>> >>>> Starbucks, Hilton, they have large sections of the operation dedicated >>>> to connecting customer-owned equipment to the Internet. >>> >>> Permit me to rephrase? The service (in the case of Comcast) is >>> intended to connect customer-owned networking equipment to the >>> internet (e.g. routers, bridges, etc.). In the case of Starbucks, >>> Hilton, etc., the expectation is that you are connecting a terminal >>> host and not a packet forwarding device. >> >> Huh? Comcast is an ISP because they give you a modem to connect >> between the coax and your ethernet port but Starbucks isn't because >> you connect to a wifi access point instead? >> > >Comcast expects most of their customers to be attaching routers, not >computers to the modem. > >Starbucks does NOT expect you to be associating a router with their wifi. > >I thought I was pretty clear about that above, but perhaps you have >trouble understanding the distinction I am drawing between packet >forwarding equipment and packet terminating hosts. I thought I was clear, >I apologize if I was not. > >>> I think getting into this level of semantic detail is a clear case of >>>reductio ad absurdum. >> >> I'll say it is! > >You went there. > >> The point here is that 21st century networks don't look like the >> dialup+webhost ISP of 1997, nor do they look like the "our employees >> have Netscape and Eudora" end-user of 1997. Attempts to shoehorn 21st >> century networks into those obsolete definitions frankly come up >> looking pretty stupid. > >That doesn't mean that one size fits all, either. > >> What we *do* see is organizations managing IP addresses in several ways: >> >> 1. assigned to organization-owned infrastructure under the control of >> the organization's employees > >End-user. > >> 2. assigned long-term to exclusive use by the organization's customers >>or users > >LIR/ISP in most cases. > >> 3. ephemerally assigned to exclusive use by the organization's >> customers or users > >Could go either way, but most likely LIR/ISP if customers and End-user if >users. > >> 4. reserved for future use > >Not sure what this means in this context, so very hard to make a >meaningful reply. > >> And we see that most organizations do a mix of all of these things, >> not one or the other. > >Actually, I would say that most organizations fit into 1 or 2 pretty >readily most of the time and we are seeing a growing, but still small >number of corner cases that are more difficult to classify. > >Nonetheless, treating all organizations the same would definitely be >either grossly unfair to those in category 1, grossly unfair to those in >category 2, or both IMHO. > >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 info at arin.net if you experience any issues. From jcurran at arin.net Fri Jul 19 10:38:29 2013 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2013 14:38:29 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: On Jul 19, 2013, at 8:57 AM, "Alexander, Daniel" wrote: > I don't think you work for Comcast or Starbucks, so speaking for them as > to what they expect is incorrect. I do work for one of them and cannot > speak for what they expect. Folks - It is probably best whenever possible for folks to use references based on the types of networks, rather than particular companies. For example: "Cable companies expect most of their customers to be attaching routers, not computers to the modem." "Coffee shops do NOT expect you to be associating a router with their wifi." Doing it in this manner also avoids some potential legal issues that David Farmer noted earlier in this thread. FYI (and Thanks!) /John John Curran President and CEO ARIN From owen at delong.com Fri Jul 19 10:52:42 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Jul 2013 10:22:42 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: <37352D5C-D12E-4CF9-A7CA-74900222FE63@delong.com> On Jul 19, 2013, at 9:27 AM, "Alexander, Daniel" wrote: > Owen, > > I don't think you work for Comcast or Starbucks, so speaking for them as > to what they expect is incorrect. I do work for one of them and cannot > speak for what they expect. In general, I would agree with you. In this specific case, I'll argue that I have relatively direct knowledge? 1. I am a Comcast customer and it has been made very clear to me through multiple interactions with them that my attaching a router and having a network infrastructure within my premises attached to their service is not a surprise to them and well within their expectations. 2. If you believe I am wrong about Starbucks, I suggest this experiment (yes, I have tried this): 1. Bring several devices and a router with you to Starbucks. 2. Connect the router to the Starbucks Wifi and use it to run a LAN for the other devices treating the Starbucks wifi as an upstream connection. In each and every case where I have conducted this experiment, Starbucks has chosen to make it clear to me that this is an unexpected and unwelcome use of their network. So? While I don't work for either one of them, both have chosen to communicate their expectations to me during my actual use of their services and I have chosen to repeat what was communicated to me here. Owen > > -Dan Alexander > Speaking only for myself and not representing my employer > > > On 7/18/13 11:59 PM, "Owen DeLong" wrote: > >> >> >> Sent from my iPad >> >> On Jul 18, 2013, at 1:13 AM, William Herrin wrote: >> >>> On Wed, Jul 17, 2013 at 8:54 PM, Owen DeLong wrote: >>>> On Jul 17, 2013, at 5:00 PM, William Herrin wrote: >>>>> On Wed, Jul 17, 2013 at 5:18 PM, Owen DeLong wrote: >>>>>> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >>>>>>> What about Comcast? They're in the business of providing cable >>>>>>> television service. They'll also provide you with Internet access on >>>>>>> the same coax cable with the modem they rent you. >>>>>>> >>>>>>> ISP or end-user? >>>>>> >>>>>> The service is intended to be used to connect customer-owned >>>>>> equipment to the internet. As such, they are clearly in the LIR/ISP >>>>>> realm. >>>>> >>>>> Starbucks, Hilton, they have large sections of the operation dedicated >>>>> to connecting customer-owned equipment to the Internet. >>>> >>>> Permit me to rephrase? The service (in the case of Comcast) is >>>> intended to connect customer-owned networking equipment to the >>>> internet (e.g. routers, bridges, etc.). In the case of Starbucks, >>>> Hilton, etc., the expectation is that you are connecting a terminal >>>> host and not a packet forwarding device. >>> >>> Huh? Comcast is an ISP because they give you a modem to connect >>> between the coax and your ethernet port but Starbucks isn't because >>> you connect to a wifi access point instead? >>> >> >> Comcast expects most of their customers to be attaching routers, not >> computers to the modem. >> >> Starbucks does NOT expect you to be associating a router with their wifi. >> >> I thought I was pretty clear about that above, but perhaps you have >> trouble understanding the distinction I am drawing between packet >> forwarding equipment and packet terminating hosts. I thought I was clear, >> I apologize if I was not. >> >>>> I think getting into this level of semantic detail is a clear case of >>>> reductio ad absurdum. >>> >>> I'll say it is! >> >> You went there. >> >>> The point here is that 21st century networks don't look like the >>> dialup+webhost ISP of 1997, nor do they look like the "our employees >>> have Netscape and Eudora" end-user of 1997. Attempts to shoehorn 21st >>> century networks into those obsolete definitions frankly come up >>> looking pretty stupid. >> >> That doesn't mean that one size fits all, either. >> >>> What we *do* see is organizations managing IP addresses in several ways: >>> >>> 1. assigned to organization-owned infrastructure under the control of >>> the organization's employees >> >> End-user. >> >>> 2. assigned long-term to exclusive use by the organization's customers >>> or users >> >> LIR/ISP in most cases. >> >>> 3. ephemerally assigned to exclusive use by the organization's >>> customers or users >> >> Could go either way, but most likely LIR/ISP if customers and End-user if >> users. >> >>> 4. reserved for future use >> >> Not sure what this means in this context, so very hard to make a >> meaningful reply. >> >>> And we see that most organizations do a mix of all of these things, >>> not one or the other. >> >> Actually, I would say that most organizations fit into 1 or 2 pretty >> readily most of the time and we are seeing a growing, but still small >> number of corner cases that are more difficult to classify. >> >> Nonetheless, treating all organizations the same would definitely be >> either grossly unfair to those in category 1, grossly unfair to those in >> category 2, or both IMHO. >> >> 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 info at arin.net if you experience any issues. From bill at herrin.us Fri Jul 19 13:08:31 2013 From: bill at herrin.us (William Herrin) Date: Fri, 19 Jul 2013 13:08:31 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <37352D5C-D12E-4CF9-A7CA-74900222FE63@delong.com> References: <37352D5C-D12E-4CF9-A7CA-74900222FE63@delong.com> Message-ID: On Fri, Jul 19, 2013 at 10:52 AM, Owen DeLong wrote: > 2. If you believe I am wrong about Starbucks, I suggest this experiment (yes, I have tried this): > > 1. Bring several devices and a router with you to Starbucks. > 2. Connect the router to the Starbucks Wifi and use it to run a LAN for the other devices > treating the Starbucks wifi as an upstream connection. http://hight3ch.com/wp-content/uploads/2008/02/starbucks_desktop.jpg http://coolpicsbro.com/post/33014 Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SRyerse at eclipse-networks.com Fri Jul 19 14:45:26 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 19 Jul 2013 18:45:26 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <3E84A41D-B879-4A83-9A02-8D6AEA8A537A@arin.net> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu><"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads><"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@E NI-M><"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com><5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli ><5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <"e-networks.com"@mac.com> <"5B9E90747FA2 974D91A54FCFA1B8AD120137D6F296"@ENI-MAIL.eclipse-networks.com><"51E4 80E0.7070606"@umn.edu><5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL. eclipse-networks.com><1965D811-AABF-4B07-A578-3FA253C3947A@arin.net><5B9E90 747FA2974D91A54FCFA1B8AD120137D70DFE@ENI-MAIL.eclipse-networks.com><39D8D42 8-269E-469A-859C-5CF27B5A5EC9@delong.com><5B9E90747FA2974D91A54FCFA1B8AD120 13!A431454@ENI-MAIL.eclipse-networks.com><57519C53-DECC-4956-B1E1-025E1DA55 38A@delong.com><5B9E90747FA2974D91A54FCFA1B8AD12013A434F32@ENI-MAIL.eclipse-networks.com> <3E84A41D-B879-4A83-9A02-8D6AEA8A537A@arin.net> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013B663947@ENI-MAIL.eclipse-networks.com> John Curran said below: You believe that the update was a major change to the mission, but in truth it was simply an attempt to more accurately reflect the current mission. So John, when did this community have a chance to discuss and have input to IF the Mission should change? (And I'm not talking about technical issues and changes.) Section 5 of the ARIN Policy Development Process says in part: "1) in compliance with law and ARIN's mission, and 2) developed via open and transparent processes". This document of course concerns Internet Number Resources and it does state that policies must be in compliance with ARIN's mission and be developed openly. This document obviously does not cover making changes to the Mission Statement but since policies must comply with ARINs mission, I think it makes sense to be open and transparent with this Community by soliciting input when making changes to the Mission Statement. After all this is the Community ARIN was created to serve. The suggestion link below for changes to the Mission Statement is good but putting out an actual change the board is considering for input would be much better. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Thursday, July 18, 2013 8:58 AM To: Steven Ryerse Cc: arin-ppml at arin.net List Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised On Jul 18, 2013, at 12:23 AM, Steven Ryerse wrote: > I would say that if something big is contemplated such as a Mission Change, which is what I believe this new Mission Statement is, why would ARIN not automatically solicit input on a proposed Mission Statement change from this community? You believe that the update was a major change to the mission, but in truth it was simply an attempt to more accurately reflect the current mission. > John has said many times including under oath that ARIN implements policies that this community wants. If ARIN changes the Mission Statement without soliciting input from this community on the proposed changes, then in my opinion ARIN is not honoring the spirit of their long standing commitment to include this community in policy decisions - since all policies should flow from and be aligned with the Mission Statement. We likely have a fundamental disagree on that point, in that the mission statement states what ARIN does, whereas number resource policy defines the rules for "how" we do it. The update to the mission statement was actually trying to make this very point more clear, i.e. ARIN (the organization) facilitates development of the policy _by the community_. > I disagree and maybe we agree that we disagree here, but this is at the heart of what I think has been wrong with policy making. Assuming by greenfield space you mean that there were plenty of IPv4 addresses available then, I don't see any reason why the depletion of IPv4 should change ARIN's Mission or change ARIN's primary mission to Allocate. ARIN's mission, from day one has included both management and allocation of number resources - refer the NSF's press release re ARIN's formation which states as much > I think the previous Mission Statement is elegant and was constructed very well. Reading it now I think it still does an excellent job of describing ARIN's mission today. A simple change to it to add that the scope that ARIN is now focused on Internet resources in this geographical region is all it needs to be current. Maybe we agree to disagree here too, but I think the new Mission Statement does change the mission. WORDS ARE A POWERFUL THING. We do indeed disagree. Actual community-developed policy for number resource management with should not be pre-empted by"implied" number resource policy that you perceive to be in the mission statement... Note that there are actual Principles of Internet Number Resource Policy" that are beyond the communities ability to directly change - these are actually in the Policy Development Process, Part 1, Section 4 - " 4. Principles of Internet Number Resource Policy Internet number resource policy must satisfy three important principles, specifically: 1) enabling fair and impartial number resource administration, 2) technically sound (providing for uniqueness and usability of number resources), and 3) supported by the community. 4.1. Enabling Fair and Impartial Number Resource Administration Internet number resources must be managed with appropriate stewardship and care. ... " These principles have been affirmed by the ARIN Board of Trustees (after a multiple year update process, including several rounds of community comment) as being an inherent part of Policy Development Process. The ARIN AC is responsible for assessing proposed changes to policy against these principles. > I think the second most important change to the Mission Statement is the removal of the word "stewardship" so I agree with you on that completely! There has been comments in this community about stewardship in a current policy proposal in the last week - but with that word specifically removed from the new Mission Statement - maybe we should no longer be discussing that. (I think we should be discussing stewardship by the way but now our mission is different here.) While the concept of stewardship is well-understood (i.e. the careful management of a resource on behalf of another), the determination of what exactly constitutes good stewardship of number resources is best left to community-developed policy. Whether the phrase is included in the mission statement (or not) does not clarify whether a particular proposed policy change is good stewardship, that ultimately is for the community to decide. If you believe that a proposed policy change would be contrary to good stewardship, please point that out on this mailing list for the AC to include in their assessment. > It's not too late for ARIN to submit the current Mission Statement to this community for input. Counting you Owen, there are at least two of us in this community that would have liked to have some input. Are you listening John? "Are you listening John?" Always. Please submit any suggestions for improvement to the Mission Statement to the ARIN Consultation and Suggestion Process These will be periodically reviewed by ARIN staff, and brought to the ARIN Board for consideration for update to the mission statement (something we should not be doing very often.) Note that we presently have one suggestion already for changing the mission statement Comments from the community on suggestions may be submitted on the arin-consult mailing list, which is open to the public. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Fri Jul 19 14:56:40 2013 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2013 18:56:40 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013B663947@ENI-MAIL.eclipse-networks.com> References: <"01f601ce7e73$04068cc 0 $0c13a640$"@tndh.net> <51DF46C3.9020900@umn.edu> <"DE229826F48ABD4CBF754E5AA6C F C14B21E8F2D8BE"@WP40044.corp.ads> <"CAJvB4t=ta6YMtUvGS0XJiqQ2vkxcEO1wXnwcNqs Vn S7EHe5YAQ"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6EF04@E> <"CAC1-dt=fdL_=qxfXGoz6pj3sU5TJ+vUEVugyr3gbhGDDUUKLm g"@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F198@ENI-MAIL.ecli> <5B9E90747FA2974D91A54FCFA1B8AD120137D6F21A@ENI-MAIL.eclips> <"5B9E90747FA2 974D91A54FCFA1B8AD120137D6F296"@ENI-MAIL.eclipse-networks.com> <"51E4 80E0.7070606"@umn.edu> <5B9E90747FA2974D91A54FCFA1B8AD120137D70C8D@ENI-MAIL.eclipse-networks.com> <1965D811-AABF-4B07-A578-3FA253C3947A@arin.net> <"5B9E90 747FA2974D91A54FCFA1B8AD120137D70DFE"@ENI-MAIL.eclipse-networks.com> <"39D8D42 8-269E-469A-859C-5CF27B5A5EC9"@delong.com> <"57519C53-DECC-4956-B1E1-025E1DA55 38A"@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12013A434F32@ENI-MAIL.eclipse-networks.com> <3E84A41D-B879-4A83-9A02-8D6AEA8A537A@arin.net> <5B9E90747FA2974D91A54FCFA1B8AD12013B663947@ENI-MAIL.eclipse-networks.com> Message-ID: <3D804A12-8D96-4E4D-BAF0-D777DD410747@arin.net> On Jul 19, 2013, at 2:45 PM, Steven Ryerse wrote: > ... > The suggestion link below for changes to the Mission Statement is good but putting out an actual change the board is considering for input would be much better. Steve - I believe I said exactly that on this list two days ago; specifically, that we would bring any future changes to the community for feedback via the consultation process - "While the change was intended to improve clarity, the fact that it could be read otherwise is definitely an indication that the process of changing the Mission statement needs more care. I believe that (in the future) the ARIN consultation process should be used to apprise the community of any intended change and receive feedback thereon, and will proceed this way in the future if at all possible." FYI, /John John Curran President and CEO ARIN From Daniel_Alexander at Cable.Comcast.com Sun Jul 21 23:33:22 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 22 Jul 2013 03:33:22 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: Message-ID: Hello All, I have submitted proposal text to facilitate this discussion. I am sure there will be many comments and changes, but wanted to provide a starting point. This proposal is an attempt to simplify one part of the NRPM in a way that is easily understood even though it intentionally leaves other parts unresolved. This was done to keep the scope to something that could realistically be discussed. There is also a red-lined version of section four attached to this email that illustrates the proposed changes. The document strikes through the text suggested to be removed, and the suggested additions are in bold and italicized. Everything in a standard font is pre-existing text. Here is a summary of the suggested requirements that would change: * Minimum allocation for a single-homed ISP is reduced from a /20 to /22. * Minimum allocation for a multi-homed ISP is reduced from a /22 to a /24. * The distinction between subscriber members who are before or after a one year anniversary is removed. * Minimum assignments for a single-homed end user is reduced from a /20 to a /22. * The requirement that multi-homed, end-user assignments smaller than a /20 be made from a block reserved for that purpose is removed. * The utilization requirements on an initial end-user assignment changes from 25% immediate, 50% within one year to 80% within three months. This is offset by the lowering of the minimum block size requirement for single-homed networks. * The timeframe for additional ISP allocations is changed from three months back to one year. * The special section for the Caribbean region is integrated into the same requirements as the rest of the region with the existing /22 and the addition of an option for a multi-homed /24. Sincerely, Dan Alexander Speaking only for myself. On 7/18/13 12:16 PM, "Matthew Wilder" wrote: >Hi David, > >I think this is a great way of looking at. NRPM could be so much >simpler, but in a multi-stakeholder world, we all see the tendency for >policy changes to complicate, not simplify NRPM. The only way to >simplify NRPM to a reasonable (sane) state is to start with a blank sheet >of paper, as you say. Our current NRPM is just shy of 15,000 words. The >sections which really need to be updated to accomplish your stated >objective are section 4 and section 6, which combined contain 8,356 >words. In my mind a sane NRPM would have half that many words. > >If you constrain the efforts simply to merging any policy which >distinguishes between End Users and ISPs, you will have around 4,000 >words in scope. I imagine the majority of challenge faced in this >activity will be merging section 4.2 with 4.3, with several topics sure >to create quite the discussion (3 month allocations for ISPs vs 12 months >for End Users, Registration for downstream customers to name two). > >The way I could imagine finding some success in the overarching ambitions >is to define what sections of NRPM we are interested in transforming, and >by contrast those which we believe should stand. I believe that the >majority of content outside section 4 and section 6 is reasonable enough. > I also believe that your intent is primarily to simplify the NRPM as it >relates to allocation of IPv4 and IPv6 resources, so likely the energy >should naturally focus on those 2 sections. > >If the community is in support of re-writing those sections of NRPM, the >two following topics should be considered for discussion (and possibly >more I have not identified): > >1. Will three month allocations apply also to End-Users as it does to >ISPs? This is going to be the biggest bone of contention as I see it, >and the big reason why many would still see value in a distinction >between ISP and End-User, despite lines blurring as many have observed. >I work for an ISP, and I see the similarities of hotels, coffee shops, >CDNs, cloud providers and so on. To what set or subset of Orgs should >the three month allocation apply? Merging End-Users and ISPs in policy >will be challenging here. > >2. What reassignments need to be registered for the global community's >benefit in a paradigm which no longer distinguishes between ISP and >End-User? I would suggest that static assignments of a certain size to >entities outside the Organization specified as the resource holder should >be registered. This mean Starbucks and the Hyatt don't have to register >their DHCP pools used by their customers (although maybe a record of that >DHCP would be desirable). In any case, this needs to be thought through >at a higher level and then specifications laid out. > >I am certainly interested in seeing what other have to say. It may be >very difficult to parse what can be reasonably removed from expectations >of ISPs in order to align with End-Users, and conversely how happy >End-Users will be to share the 3-month allocation policy with ISPs. If >the majority of value is seen by many in simple alignment of initial >allocation and assignment (and to some degree subsequent allocation / >assignment), I believe the policy changes will be much easier to manage >and build consensus around. > >Cheers, >Matthew Wilder > > >-----Original Message----- >From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >Behalf Of David Huberman >Sent: July 18, 2013 01:36 AM >To: arin-ppml at arin.net >Subject: Re: [arin-ppml] Initial ISP Allocation Policy > >Hello everyone, > >I would like to thank everyone for a very good discussion in this thread. >First I'll give a very brief summary of the discussion so far, and then I >have a solution to float to the list for feedback. > >Myself, Dan, Bill, and Steven have posted in favor of the high level >concept that the differentiation in ARIN policy between enterprise >networks and provider networks is no longer productive or relevant. Owen >may agree in principle, but cautions us to be very careful with how we >proceed. He is concerned that an effective "one size fits all" solution >may be very difficult to design. George offers us an alternative >nomenclature to consider (NSP v. ISP). > >I would like to now shift the discussion to how we approach potentially >collapsing the two categories into one so that future interactions with >ARIN are conducted under policy language which is relevant in 2014 and >beyond. > >I agree with Dan that a wholesale paradigm shift in ARIN policy can only >be accomplished with multiple proposals. There would be quite a few >sections to change (with each change requiring careful consideration by >the community). Moreover, I think we must be sensitive to ARIN's need to >react to the possible impacts to both the financial and workflow modeling >that would result from any changes we propose. > >At the same time, incremental change in NRPM is actually really hard. If >this were 5 years ago, I would probably work very hard to help effect >incremental change. But I think ARIN and the community have together >failed to react to changes in the market over the last 15 years, and it >is time to consider very big change. Let's get NRPM into a sane state for >2014 and beyond. > >In an effort to roll up sleeves and be productive, please indulge me >while I lay out one potential vision for what a sane NRPM might look >like. I warn you, good reader, that some of what I propose is very >radical. > >- A section on obtaining initial IPv4 addresses from ARIN. No >distinction between end-users and ISPs. No distinction between >single-homed and multi-homed deployments (*if you don't understand why >the difference has no virtue, ping me on or off list and I will show you >the math as I see it). Text might look something like: > > "In order to receive an initial allocation from ARIN, an organization >must: > > - demonstrate they operate an IP network that requires > IPv4 addresses to deploy and/or grow; and > > - provide a numbering plan detailing how IPv4 addresses > will be used in the first 180 days upon receiving an allocation. > > ARIN will review and verify the data provided, and provide for the >organization's 6 month need." > >- A section on obtaining additional blocks, which still outlines the 80% >rule. ("If you've efficiently used what you have, you can have more" is a >technically sound concept that does not need much fixing.) Platform >differences which are already fleshed out in NRPM (e.g., residential >market area provider networks with their different metrics than more >common buildouts) can and should remain. > >- We would have to figure out what to do with the requirement to SWIP, as >the requirement is predicated on the classification of "ISP" actually >existing (which it would not). That might need a working group to >reconcile. > >- A section on obtaining initial IPv6 addresses from ARIN. Given that >IPv6 is still very much in its infancy, I really would like to see very >simple NRPM text which allows requestors to self-select what size block >they need. The only barrier to abuse or silliness would be the fee >schedule. It is arrogant and technically indefensible that ARIN policy >today tries to dictate what a network does, and does not, justify as far >as block size. IPv6 is much too immature for ARIN policy to presume such >wisdom. > >- A section on obtaining additional IPv6 addresses from ARIN. Existing >text in 6.5.3 is probably good enough for today, as there are only a >handful of networks in the world with any experience needing additional >IPv6 addresses due to efficient use of an initial block. Obtaining >additional IPv6 addresses is a topic for many years from now, not today. > >Do you think any of this has value? Would it accomplish the overarching >goal of improving ARIN policy to make it relevant to network operators in >2014 and beyond? What would your sane NRPM look like? > >With regards, >David > > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to the ARIN >Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: proposed_text_changes.pdf Type: application/x-msword Size: 104087 bytes Desc: proposed_text_changes.pdf URL: From David.Huberman at microsoft.com Mon Jul 22 11:26:03 2013 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 22 Jul 2013 15:26:03 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: <1564f66d6a354dfeb6f05c39c4ba49ab@BN1PR03MB250.namprd03.prod.outlook.com> Dan, Thank you for moving this discussion to the next step by providing excellent draft policy proposal text (and providing a redlined PDF). I support this draft text. I have two comments for your consideration: 1) Since we're cleaning up NRPM, let's remove section "4.2.2 Annual Renewal". This text does not help answer the question, "Do I qualify for number resources from ARIN?" and is already sufficiently covered by the RSA text. 2) The SWIP section (4.2.8.7.1 Reassignment Information): the way the new text is written, it seems to me that if $ENTERPRISE assigns a /28 to a $PURPOSE, that has to be SWIPed. Would the text be improved if the opening sentence read, "Each IPv4 assignment to an external customer" or somesuch? With regards, David From bill at herrin.us Mon Jul 22 13:39:23 2013 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jul 2013 13:39:23 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: On Sun, Jul 21, 2013 at 11:33 PM, Alexander, Daniel wrote: > * Minimum allocation for a single-homed ISP is reduced from a /20 to /22. > * Minimum assignments for a single-homed end user is reduced from a /20 to > a /22. Hi Daniel, I strongly disagree with these two proposed changes. There is no technical penalty for allowing multihomed registrants to get their addresses directly from ARIN: their routes will be present in the BGP table regardless of where they get the addresses. This is not true of single-homed end users who would generally not have a presence in the BGP table unless they get their addresses from the RIR. As we've discussed principles in recent weeks, we have broad agreement that it's ARIN's job to make scalable routing possible. Right now, that means having single-homed users get their numbers from their upstream. The changes would run counter without apparent gain in one of the other areas discussed as candidate principles. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rcarpen at network1.net Mon Jul 22 13:56:31 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 22 Jul 2013 13:56:31 -0400 (EDT) Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: <1974582021.198115.1374515791800.JavaMail.zimbra@network1.net> Bill, I strongly disagree with your disagreement :-) and fully support the proposed changes. I have worked with several small rural ISPs who really only have one option for upstream connectivity. In most cases, the upstream refuses to give out any more IP addresses. Some of these ISPs would be fine with a /21, while others would need a /20, but cannot get a aggregate /20 from the upstream. thanks, -Randy ----- Original Message ----- > On Sun, Jul 21, 2013 at 11:33 PM, Alexander, Daniel > wrote: > > * Minimum allocation for a single-homed ISP is reduced from a /20 to /22. > > * Minimum assignments for a single-homed end user is reduced from a /20 to > > a /22. > > Hi Daniel, > > I strongly disagree with these two proposed changes. There is no > technical penalty for allowing multihomed registrants to get their > addresses directly from ARIN: their routes will be present in the BGP > table regardless of where they get the addresses. This is not true of > single-homed end users who would generally not have a presence in the > BGP table unless they get their addresses from the RIR. > > As we've discussed principles in recent weeks, we have broad agreement > that it's ARIN's job to make scalable routing possible. Right now, > that means having single-homed users get their numbers from their > upstream. The changes would run counter without apparent gain in one > of the other areas discussed as candidate principles. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From SRyerse at eclipse-networks.com Mon Jul 22 14:16:14 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 22 Jul 2013 18:16:14 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013B68980A@ENI-MAIL.eclipse-networks.com> I mostly would support. Maybe I don't quite understand your logic but it seems that changing utilization to be 80% after 3 months works at cross purposes of waiting a year for an additional allocation as that rate would use up the block in around 4 months with 8 months or so left in the year before eligible for another allocation. I could live with reducing the minimum sizes but I'm guessing some won't like the effect on the routing table to do that. I do think these changes would be positive a whole. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Sunday, July 21, 2013 11:33 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Initial ISP Allocation Policy Hello All, I have submitted proposal text to facilitate this discussion. I am sure there will be many comments and changes, but wanted to provide a starting point. This proposal is an attempt to simplify one part of the NRPM in a way that is easily understood even though it intentionally leaves other parts unresolved. This was done to keep the scope to something that could realistically be discussed. There is also a red-lined version of section four attached to this email that illustrates the proposed changes. The document strikes through the text suggested to be removed, and the suggested additions are in bold and italicized. Everything in a standard font is pre-existing text. Here is a summary of the suggested requirements that would change: * Minimum allocation for a single-homed ISP is reduced from a /20 to /22. * Minimum allocation for a multi-homed ISP is reduced from a /22 to a /24. * The distinction between subscriber members who are before or after a one year anniversary is removed. * Minimum assignments for a single-homed end user is reduced from a /20 to a /22. * The requirement that multi-homed, end-user assignments smaller than a /20 be made from a block reserved for that purpose is removed. * The utilization requirements on an initial end-user assignment changes from 25% immediate, 50% within one year to 80% within three months. This is offset by the lowering of the minimum block size requirement for single-homed networks. * The timeframe for additional ISP allocations is changed from three months back to one year. * The special section for the Caribbean region is integrated into the same requirements as the rest of the region with the existing /22 and the addition of an option for a multi-homed /24. Sincerely, Dan Alexander Speaking only for myself. On 7/18/13 12:16 PM, "Matthew Wilder" wrote: >Hi David, > >I think this is a great way of looking at. NRPM could be so much >simpler, but in a multi-stakeholder world, we all see the tendency for >policy changes to complicate, not simplify NRPM. The only way to >simplify NRPM to a reasonable (sane) state is to start with a blank >sheet of paper, as you say. Our current NRPM is just shy of 15,000 >words. The sections which really need to be updated to accomplish your >stated objective are section 4 and section 6, which combined contain >8,356 words. In my mind a sane NRPM would have half that many words. > >If you constrain the efforts simply to merging any policy which >distinguishes between End Users and ISPs, you will have around 4,000 >words in scope. I imagine the majority of challenge faced in this >activity will be merging section 4.2 with 4.3, with several topics sure >to create quite the discussion (3 month allocations for ISPs vs 12 >months for End Users, Registration for downstream customers to name two). > >The way I could imagine finding some success in the overarching >ambitions is to define what sections of NRPM we are interested in >transforming, and by contrast those which we believe should stand. I >believe that the majority of content outside section 4 and section 6 is reasonable enough. > I also believe that your intent is primarily to simplify the NRPM as >it relates to allocation of IPv4 and IPv6 resources, so likely the >energy should naturally focus on those 2 sections. > >If the community is in support of re-writing those sections of NRPM, >the two following topics should be considered for discussion (and >possibly more I have not identified): > >1. Will three month allocations apply also to End-Users as it does to >ISPs? This is going to be the biggest bone of contention as I see it, >and the big reason why many would still see value in a distinction >between ISP and End-User, despite lines blurring as many have observed. >I work for an ISP, and I see the similarities of hotels, coffee shops, >CDNs, cloud providers and so on. To what set or subset of Orgs should >the three month allocation apply? Merging End-Users and ISPs in policy >will be challenging here. > >2. What reassignments need to be registered for the global community's >benefit in a paradigm which no longer distinguishes between ISP and >End-User? I would suggest that static assignments of a certain size to >entities outside the Organization specified as the resource holder >should be registered. This mean Starbucks and the Hyatt don't have to >register their DHCP pools used by their customers (although maybe a >record of that DHCP would be desirable). In any case, this needs to be >thought through at a higher level and then specifications laid out. > >I am certainly interested in seeing what other have to say. It may be >very difficult to parse what can be reasonably removed from >expectations of ISPs in order to align with End-Users, and conversely >how happy End-Users will be to share the 3-month allocation policy with >ISPs. If the majority of value is seen by many in simple alignment of >initial allocation and assignment (and to some degree subsequent >allocation / assignment), I believe the policy changes will be much >easier to manage and build consensus around. > >Cheers, >Matthew Wilder > > >-----Original Message----- >From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >Behalf Of David Huberman >Sent: July 18, 2013 01:36 AM >To: arin-ppml at arin.net >Subject: Re: [arin-ppml] Initial ISP Allocation Policy > >Hello everyone, > >I would like to thank everyone for a very good discussion in this thread. >First I'll give a very brief summary of the discussion so far, and then >I have a solution to float to the list for feedback. > >Myself, Dan, Bill, and Steven have posted in favor of the high level >concept that the differentiation in ARIN policy between enterprise >networks and provider networks is no longer productive or relevant. >Owen may agree in principle, but cautions us to be very careful with >how we proceed. He is concerned that an effective "one size fits all" >solution may be very difficult to design. George offers us an >alternative nomenclature to consider (NSP v. ISP). > >I would like to now shift the discussion to how we approach potentially >collapsing the two categories into one so that future interactions with >ARIN are conducted under policy language which is relevant in 2014 and >beyond. > >I agree with Dan that a wholesale paradigm shift in ARIN policy can >only be accomplished with multiple proposals. There would be quite a >few sections to change (with each change requiring careful >consideration by the community). Moreover, I think we must be >sensitive to ARIN's need to react to the possible impacts to both the >financial and workflow modeling that would result from any changes we propose. > >At the same time, incremental change in NRPM is actually really hard. >If this were 5 years ago, I would probably work very hard to help >effect incremental change. But I think ARIN and the community have >together failed to react to changes in the market over the last 15 >years, and it is time to consider very big change. Let's get NRPM into >a sane state for >2014 and beyond. > >In an effort to roll up sleeves and be productive, please indulge me >while I lay out one potential vision for what a sane NRPM might look >like. I warn you, good reader, that some of what I propose is very >radical. > >- A section on obtaining initial IPv4 addresses from ARIN. No >distinction between end-users and ISPs. No distinction between >single-homed and multi-homed deployments (*if you don't understand why >the difference has no virtue, ping me on or off list and I will show >you the math as I see it). Text might look something like: > > "In order to receive an initial allocation from ARIN, an organization >must: > > - demonstrate they operate an IP network that requires > IPv4 addresses to deploy and/or grow; and > > - provide a numbering plan detailing how IPv4 addresses > will be used in the first 180 days upon receiving an allocation. > > ARIN will review and verify the data provided, and provide for the >organization's 6 month need." > >- A section on obtaining additional blocks, which still outlines the >80% rule. ("If you've efficiently used what you have, you can have >more" is a technically sound concept that does not need much fixing.) >Platform differences which are already fleshed out in NRPM (e.g., >residential market area provider networks with their different metrics >than more common buildouts) can and should remain. > >- We would have to figure out what to do with the requirement to SWIP, >as the requirement is predicated on the classification of "ISP" >actually existing (which it would not). That might need a working >group to reconcile. > >- A section on obtaining initial IPv6 addresses from ARIN. Given that >IPv6 is still very much in its infancy, I really would like to see very >simple NRPM text which allows requestors to self-select what size block >they need. The only barrier to abuse or silliness would be the fee >schedule. It is arrogant and technically indefensible that ARIN policy >today tries to dictate what a network does, and does not, justify as >far as block size. IPv6 is much too immature for ARIN policy to >presume such wisdom. > >- A section on obtaining additional IPv6 addresses from ARIN. Existing >text in 6.5.3 is probably good enough for today, as there are only a >handful of networks in the world with any experience needing additional >IPv6 addresses due to efficient use of an initial block. Obtaining >additional IPv6 addresses is a topic for many years from now, not today. > >Do you think any of this has value? Would it accomplish the >overarching goal of improving ARIN policy to make it relevant to >network operators in >2014 and beyond? What would your sane NRPM look like? > >With regards, >David > > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to the ARIN >Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. >_______________________________________________ >PPML >You are receiving this message because you are subscribed to the ARIN >Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. From bill at herrin.us Mon Jul 22 14:22:53 2013 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jul 2013 14:22:53 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <1974582021.198115.1374515791800.JavaMail.zimbra@network1.net> References: <1974582021.198115.1374515791800.JavaMail.zimbra@network1.net> Message-ID: On Mon, Jul 22, 2013 at 1:56 PM, Randy Carpenter wrote: > I strongly disagree with your disagreement :-) and fully support the proposed changes. > > I have worked with several small rural ISPs who really only have one option for > upstream connectivity. In most cases, the upstream refuses to give out any more > IP addresses. Some of these ISPs would be fine with a /21, while others would > need a /20, but cannot get a aggregate /20 from the upstream. Hi Randy, BS. You can add satellite coverage anywhere, and I do mean anywhere. More, nearly all rural ISPs can contract a private point to point line to the nearest city with a carrier-neutral data center and pick up another ISP there. What you mean is that they can't get a second upstream at a price that's viable for their customer base. And I'll bet the same thing is true with IP addresses -- wave money and documentation at the upstream and see how fast they find more IPs for you. That's life in a post-IPv4 exhaustion world. If you can't afford it, use carrier NAT. At any rate, if Daniel ties the two proposals together, I'd bet he'll sink them both. Since the disucssion seems to focus on unifying registrant classes rather than reducing minimum allocations, I'd recommend he split the latter out. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Daniel_Alexander at Cable.Comcast.com Mon Jul 22 15:08:12 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 22 Jul 2013 19:08:12 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: Message-ID: Hello Bill, Here is my understanding of the factors I took into consideration regarding the minimum settings. * AFRINIC and LACNIC currently have a /22 minimum with no SH/MH distinction. * RIPE NCC has a /22 minimum, which also happens to be their maximum as they are in their last /8 policy phase. As I understand it, a /21 minimum would apply to a transfer. * APNIC has a /24 minimum with a /22 maximum as part of their depletion phase policies. The /24 minimum would apply to transfers without a SH/MH distinction. * Existing aggregated blocks can already be broken down to /24's through the Inter-RIR transfer policy regardless of whether they are SH or MH. * The impact in the ARIN region would be the number of single-homed organizations who could qualify for a /22, but cannot qualify for a /20, and are willing to add the additional financial obligation of being an ARIN Org and possibly having to pay for a transfer. The question that comes to mind is whether this change would have a scalable impact on the existing, estimated, 450K routes already in the table? My sense is that it would not which is how I got to the draft language. Sincerely, Dan Alexander Speaking only for myself On 7/22/13 1:39 PM, "William Herrin" wrote: >On Sun, Jul 21, 2013 at 11:33 PM, Alexander, Daniel > wrote: >> * Minimum allocation for a single-homed ISP is reduced from a /20 to >>/22. >> * Minimum assignments for a single-homed end user is reduced from a /20 >>to >> a /22. > >Hi Daniel, > >I strongly disagree with these two proposed changes. There is no >technical penalty for allowing multihomed registrants to get their >addresses directly from ARIN: their routes will be present in the BGP >table regardless of where they get the addresses. This is not true of >single-homed end users who would generally not have a presence in the >BGP table unless they get their addresses from the RIR. > >As we've discussed principles in recent weeks, we have broad agreement >that it's ARIN's job to make scalable routing possible. Right now, >that means having single-homed users get their numbers from their >upstream. The changes would run counter without apparent gain in one >of the other areas discussed as candidate principles. > >Regards, >Bill Herrin > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 From dave at goflashpoint.com Mon Jul 22 15:08:37 2013 From: dave at goflashpoint.com (David Gibbons) Date: Mon, 22 Jul 2013 15:08:37 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D60D271@USI-2K10EX02-MT.usicorp.usinternet.com> <51e6fab4.0a8ce50a.5127.ffffba9dSMTPIN_ADDED_BROKEN@mx.google.com> <647B46E4-5388-49DC-B7E7-3DD7D8EE3550@delong.com> Message-ID: @jdaniels, We've had this same argument with the Gestapo as well -- several times now. In the end we had to pull our pants down and provide: all customer names, IPs in use by those customers, etc. I would love to know how an offering like AWS or Azure feels about giving up the names of their customers and the IPs to which they have been assigned in order to get an allocation. I find it tremendously hard to believe that the larger VPS folks are having to run through the same shake down that the smaller companies do. It's laughable to consider the thought that Amazon or Microsoft would hand out the names of their clients in order to get some IP space. /dave On Wed, Jul 17, 2013 at 6:10 PM, Jon Daniels wrote: > Is a VPS company an ISP or an end user? > > ARIN told me in a ticket regarding an initial IPv4 end-user request > (this is yesterday) that the virtual server (VPS) company i work for, > is NOT an end-user, but is an ISP. Each virtual servers uses less > than a /29, and we do not do SWIP, reallocate, or reassign any IP > space. The company only provides virtual servers. > > > > On Wed, Jul 17, 2013 at 2:18 PM, Owen DeLong wrote: > > > > On Jul 17, 2013, at 4:34 PM, William Herrin wrote: > > > >> On Wed, Jul 17, 2013 at 4:02 PM, Justin Krejci > wrote: > >>> Here is my newbie and possibly naive response. > >>> > >>> Without additional details on individual cases in the list, I would > expect all of those cases to be "end-users" as none of them are in the > business of reallocating address blocks. Right or wrong I've always been > under the impression this to be the general rule of thumb: if allowed to > reallocate then you're an ISP, else end-user; maybe to back up even further > the primary purpose of the listed organizations are not to provide Internet > connectivity services nor is it their primary goal or likely even a > secondary goal. > >>> > >>> Akamai, provide effective access to 3rd party content > >>> Google, provide advertising, searching, and various web related > services > >>> U of Maryland, provide education > >>> Starbucks, provide beverages and calories in solid form > >>> Hilton/Marriott, provide hospitality > >>> Linode, provide virtual server hosting > >>> Godaddy, provide DNS/web hosting > >>> > >>> In any case, NRPM 2.6 says, "An end-user is an organization receiving > >>> assignments of IP addresses exclusively for use in its operational > >>> networks." I think all of these example cases seem to fit this wording > >>> as they are operating their identified systems within their operational > >>> networks. > >> > >> Hi Justin, > >> > >> What about Verizon Wireless? They're primarily a cellular phone > >> company, and the overwhelming majority of the phones on which IP > >> addresses are used are still on the rent-to-own plan where you have to > >> complete the 2 year contract before you actually own the phone. Untill > >> then you're just leasing the use of their equipment. > > > > It's my understanding that it is inappropriate to name particular > companies in this case, but the below applies equally well to $CELLCO, so > I'll speak to that. > > > > That's not true. If you were leasing their equipment, then you could > terminate the contract and give the equipment back to them. Instead, you > have to reimburse them for the subsidy (and possibly more in most cases). > You bought the phone at a reduced price. You agreed to a service contract > in exchange for that reduced price. If you terminate the contract early, > you are obliged to pay back said discount. That is to the same as leasing > equipment they own. > > > >> ISP or end-user? > > > > ISP? $CELLCO generally assigns a block of addresses to the phone (at > least my $CELLCO assigns a /64 to my phone) and should be registering those > assignments. Further, they are also providing a service which is intended > to provide internet access to customer-owned hardware (your lease argument > doesn't actually hold water as stated above). Even if the hardware is > leased, it still counts as hardware under the customer's control. > > > >> What about Comcast? They're in the business of providing cable > >> television service. They'll also provide you with Internet access on > >> the same coax cable with the modem they rent you. > >> > >> ISP or end-user? > > > > The service is intended to be used to connect customer-owned equipment > to the internet. As such, they are clearly in the LIR/ISP realm. > > > > 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 info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- David Gibbons Tel: 814-206-0183 Cloud My Office / 1-855-45-CLOUD -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcarpen at network1.net Mon Jul 22 15:12:18 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 22 Jul 2013 15:12:18 -0400 (EDT) Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <1974582021.198115.1374515791800.JavaMail.zimbra@network1.net> Message-ID: <1017791891.198442.1374520338958.JavaMail.zimbra@network1.net> ----- Original Message ----- > On Mon, Jul 22, 2013 at 1:56 PM, Randy Carpenter > wrote: > > I strongly disagree with your disagreement :-) and fully support the > > proposed changes. > > > > I have worked with several small rural ISPs who really only have one option > > for > > upstream connectivity. In most cases, the upstream refuses to give out any > > more > > IP addresses. Some of these ISPs would be fine with a /21, while others > > would > > need a /20, but cannot get a aggregate /20 from the upstream. > > Hi Randy, > > BS. You can add satellite coverage anywhere, and I do mean anywhere. Satellite coverage? Has there been some crazy new development that let's us do low-latency GigE+ links over satellite? > More, nearly all rural ISPs can contract a private point to point line > to the nearest city with a carrier-neutral data center and pick up > another ISP there. Not for anything even close to reasonable cost. We're talking 100+ miles of fiber that would have to be newly installed. > What you mean is that they can't get a second upstream at a price > that's viable for their customer base. Of course that is what I mean. If the companies I am talking about had billions of dollars, then there would not be an issue. But, they would also no longer be the companies I am talking about. > And I'll bet the same thing is > true with IP addresses -- wave money and documentation at the upstream > and see how fast they find more IPs for you. If it were as simple as waving (a reasonable amount of) money, everything would be fine, and we would not be having this conversation. > That's life in a > post-IPv4 exhaustion world. If you can't afford it, use carrier NAT. CGN is not exactly a good|affordable solution. I guess I am confused a bit... If the remaining addresses in the ARIN pool shouldn't go to entities that most need them, then who are they for? > At any rate, if Daniel ties the two proposals together, I'd bet he'll > sink them both. Since the disucssion seems to focus on unifying > registrant classes rather than reducing minimum allocations, I'd > recommend he split the latter out. I agree that separate proposals may be better. If we are really worried about routing table size, then we should never have reduced the needs requirement to 3-months. I have seen many cases where people now have several smaller blocks, rather than once larger, contiguous block because of that policy. I really don't think there are enough entities like I am talking about to make a huge impact. Certainly not as much impact as getting the really big ISPs with stupid deaggregated announcements to fix their policies. -Randy From Daniel_Alexander at Cable.Comcast.com Mon Jul 22 15:42:19 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 22 Jul 2013 19:42:19 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013B68980A@ENI-MAIL.eclipse-networks.com> Message-ID: Hello Steven, Can you help me understand where you interpret that someone would not be able to get another block for a year? My wording may be off. The text, "an initial block would be 80% utilized within three months", applies to someone asking for an initial registration from ARIN. It is assumed that they should be able to qualify for what they are justifying through existing assignments from an upstream and would renumber into the new block. It was an attempt to retain the concept of slow start without drawing it out in language or an explicit section. If the network operator uses this block in 3 months, or 30 days, there should be nothing preventing them from qualifying for an additional block given they meet the 80% utilization. There should be no language in the proposal restricting an operator from obtaining an approval ONLY ONCE within a year. Sincerely, Dan Alexander Speaking only for myself. On 7/22/13 2:16 PM, "Steven Ryerse" wrote: >I mostly would support. Maybe I don't quite understand your logic but it >seems that changing utilization to be 80% after 3 months works at cross >purposes of waiting a year for an additional allocation as that rate >would use up the block in around 4 months with 8 months or so left in the >year before eligible for another allocation. I could live with reducing >the minimum sizes but I'm guessing some won't like the effect on the >routing table to do that. I do think these changes would be positive a >whole. > >Steven L Ryerse >President >100 Ashford Center North, Suite 110, Atlanta, GA 30338 >770.656.1460 - Cell >770.399.9099 - Office >770.392-0076 - Fax > >? Eclipse Networks, Inc. > Conquering Complex Networks? > > >-----Original Message----- >From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >Behalf Of Alexander, Daniel >Sent: Sunday, July 21, 2013 11:33 PM >To: arin-ppml at arin.net >Subject: Re: [arin-ppml] Initial ISP Allocation Policy > >Hello All, > >I have submitted proposal text to facilitate this discussion. I am sure >there will be many comments and changes, but wanted to provide a starting >point. This proposal is an attempt to simplify one part of the NRPM in a >way that is easily understood even though it intentionally leaves other >parts unresolved. This was done to keep the scope to something that could >realistically be discussed. > >There is also a red-lined version of section four attached to this email >that illustrates the proposed changes. The document strikes through the >text suggested to be removed, and the suggested additions are in bold and >italicized. Everything in a standard font is pre-existing text. > >Here is a summary of the suggested requirements that would change: > >* Minimum allocation for a single-homed ISP is reduced from a /20 to /22. >* Minimum allocation for a multi-homed ISP is reduced from a /22 to a /24. >* The distinction between subscriber members who are before or after a >one year anniversary is removed. >* Minimum assignments for a single-homed end user is reduced from a /20 >to a /22. >* The requirement that multi-homed, end-user assignments smaller than a >/20 be made from a block reserved for that purpose is removed. >* The utilization requirements on an initial end-user assignment changes >from 25% immediate, 50% within one year to 80% within three months. This >is offset by the lowering of the minimum block size requirement for >single-homed networks. >* The timeframe for additional ISP allocations is changed from three >months back to one year. >* The special section for the Caribbean region is integrated into the >same requirements as the rest of the region with the existing /22 and the >addition of an option for a multi-homed /24. > >Sincerely, > >Dan Alexander >Speaking only for myself. > >On 7/18/13 12:16 PM, "Matthew Wilder" wrote: > >>Hi David, >> >>I think this is a great way of looking at. NRPM could be so much >>simpler, but in a multi-stakeholder world, we all see the tendency for >>policy changes to complicate, not simplify NRPM. The only way to >>simplify NRPM to a reasonable (sane) state is to start with a blank >>sheet of paper, as you say. Our current NRPM is just shy of 15,000 >>words. The sections which really need to be updated to accomplish your >>stated objective are section 4 and section 6, which combined contain >>8,356 words. In my mind a sane NRPM would have half that many words. >> >>If you constrain the efforts simply to merging any policy which >>distinguishes between End Users and ISPs, you will have around 4,000 >>words in scope. I imagine the majority of challenge faced in this >>activity will be merging section 4.2 with 4.3, with several topics sure >>to create quite the discussion (3 month allocations for ISPs vs 12 >>months for End Users, Registration for downstream customers to name two). >> >>The way I could imagine finding some success in the overarching >>ambitions is to define what sections of NRPM we are interested in >>transforming, and by contrast those which we believe should stand. I >>believe that the majority of content outside section 4 and section 6 is >>reasonable enough. >> I also believe that your intent is primarily to simplify the NRPM as >>it relates to allocation of IPv4 and IPv6 resources, so likely the >>energy should naturally focus on those 2 sections. >> >>If the community is in support of re-writing those sections of NRPM, >>the two following topics should be considered for discussion (and >>possibly more I have not identified): >> >>1. Will three month allocations apply also to End-Users as it does to >>ISPs? This is going to be the biggest bone of contention as I see it, >>and the big reason why many would still see value in a distinction >>between ISP and End-User, despite lines blurring as many have observed. >>I work for an ISP, and I see the similarities of hotels, coffee shops, >>CDNs, cloud providers and so on. To what set or subset of Orgs should >>the three month allocation apply? Merging End-Users and ISPs in policy >>will be challenging here. >> >>2. What reassignments need to be registered for the global community's >>benefit in a paradigm which no longer distinguishes between ISP and >>End-User? I would suggest that static assignments of a certain size to >>entities outside the Organization specified as the resource holder >>should be registered. This mean Starbucks and the Hyatt don't have to >>register their DHCP pools used by their customers (although maybe a >>record of that DHCP would be desirable). In any case, this needs to be >>thought through at a higher level and then specifications laid out. >> >>I am certainly interested in seeing what other have to say. It may be >>very difficult to parse what can be reasonably removed from >>expectations of ISPs in order to align with End-Users, and conversely >>how happy End-Users will be to share the 3-month allocation policy with >>ISPs. If the majority of value is seen by many in simple alignment of >>initial allocation and assignment (and to some degree subsequent >>allocation / assignment), I believe the policy changes will be much >>easier to manage and build consensus around. >> >>Cheers, >>Matthew Wilder >> >> >>-----Original Message----- >>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>Behalf Of David Huberman >>Sent: July 18, 2013 01:36 AM >>To: arin-ppml at arin.net >>Subject: Re: [arin-ppml] Initial ISP Allocation Policy >> >>Hello everyone, >> >>I would like to thank everyone for a very good discussion in this thread. >>First I'll give a very brief summary of the discussion so far, and then >>I have a solution to float to the list for feedback. >> >>Myself, Dan, Bill, and Steven have posted in favor of the high level >>concept that the differentiation in ARIN policy between enterprise >>networks and provider networks is no longer productive or relevant. >>Owen may agree in principle, but cautions us to be very careful with >>how we proceed. He is concerned that an effective "one size fits all" >>solution may be very difficult to design. George offers us an >>alternative nomenclature to consider (NSP v. ISP). >> >>I would like to now shift the discussion to how we approach potentially >>collapsing the two categories into one so that future interactions with >>ARIN are conducted under policy language which is relevant in 2014 and >>beyond. >> >>I agree with Dan that a wholesale paradigm shift in ARIN policy can >>only be accomplished with multiple proposals. There would be quite a >>few sections to change (with each change requiring careful >>consideration by the community). Moreover, I think we must be >>sensitive to ARIN's need to react to the possible impacts to both the >>financial and workflow modeling that would result from any changes we >>propose. >> >>At the same time, incremental change in NRPM is actually really hard. >>If this were 5 years ago, I would probably work very hard to help >>effect incremental change. But I think ARIN and the community have >>together failed to react to changes in the market over the last 15 >>years, and it is time to consider very big change. Let's get NRPM into >>a sane state for >>2014 and beyond. >> >>In an effort to roll up sleeves and be productive, please indulge me >>while I lay out one potential vision for what a sane NRPM might look >>like. I warn you, good reader, that some of what I propose is very >>radical. >> >>- A section on obtaining initial IPv4 addresses from ARIN. No >>distinction between end-users and ISPs. No distinction between >>single-homed and multi-homed deployments (*if you don't understand why >>the difference has no virtue, ping me on or off list and I will show >>you the math as I see it). Text might look something like: >> >> "In order to receive an initial allocation from ARIN, an organization >>must: >> >> - demonstrate they operate an IP network that requires >> IPv4 addresses to deploy and/or grow; and >> >> - provide a numbering plan detailing how IPv4 addresses >> will be used in the first 180 days upon receiving an allocation. >> >> ARIN will review and verify the data provided, and provide for the >>organization's 6 month need." >> >>- A section on obtaining additional blocks, which still outlines the >>80% rule. ("If you've efficiently used what you have, you can have >>more" is a technically sound concept that does not need much fixing.) >>Platform differences which are already fleshed out in NRPM (e.g., >>residential market area provider networks with their different metrics >>than more common buildouts) can and should remain. >> >>- We would have to figure out what to do with the requirement to SWIP, >>as the requirement is predicated on the classification of "ISP" >>actually existing (which it would not). That might need a working >>group to reconcile. >> >>- A section on obtaining initial IPv6 addresses from ARIN. Given that >>IPv6 is still very much in its infancy, I really would like to see very >>simple NRPM text which allows requestors to self-select what size block >>they need. The only barrier to abuse or silliness would be the fee >>schedule. It is arrogant and technically indefensible that ARIN policy >>today tries to dictate what a network does, and does not, justify as >>far as block size. IPv6 is much too immature for ARIN policy to >>presume such wisdom. >> >>- A section on obtaining additional IPv6 addresses from ARIN. Existing >>text in 6.5.3 is probably good enough for today, as there are only a >>handful of networks in the world with any experience needing additional >>IPv6 addresses due to efficient use of an initial block. Obtaining >>additional IPv6 addresses is a topic for many years from now, not today. >> >>Do you think any of this has value? Would it accomplish the >>overarching goal of improving ARIN policy to make it relevant to >>network operators in >>2014 and beyond? What would your sane NRPM look like? >> >>With regards, >>David >> >> >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to the ARIN >>Public Policy Mailing List (ARIN-PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-ppml >>Please contact info at arin.net if you experience any issues. >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to the ARIN >>Public Policy Mailing List (ARIN-PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-ppml >>Please contact info at arin.net if you experience any issues. > From SRyerse at eclipse-networks.com Mon Jul 22 15:47:18 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 22 Jul 2013 19:47:18 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12013B68980A@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013B68BD69@ENI-MAIL.eclipse-networks.com> I'm contrasting this: " The utilization requirements on an initial end-user assignment changes from 25% immediate, 50% within one year to 80% within three months" with this "The timeframe for additional ISP allocations is changed from three months back to one year". Since I'm just looking at your bullet points I might be missing something. As I said overall I support what you are trying to accomplish. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Alexander, Daniel [mailto:Daniel_Alexander at Cable.Comcast.com] Sent: Monday, July 22, 2013 3:42 PM To: Steven Ryerse Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Initial ISP Allocation Policy Hello Steven, Can you help me understand where you interpret that someone would not be able to get another block for a year? My wording may be off. The text, "an initial block would be 80% utilized within three months", applies to someone asking for an initial registration from ARIN. It is assumed that they should be able to qualify for what they are justifying through existing assignments from an upstream and would renumber into the new block. It was an attempt to retain the concept of slow start without drawing it out in language or an explicit section. If the network operator uses this block in 3 months, or 30 days, there should be nothing preventing them from qualifying for an additional block given they meet the 80% utilization. There should be no language in the proposal restricting an operator from obtaining an approval ONLY ONCE within a year. Sincerely, Dan Alexander Speaking only for myself. On 7/22/13 2:16 PM, "Steven Ryerse" wrote: >I mostly would support. Maybe I don't quite understand your logic but >it seems that changing utilization to be 80% after 3 months works at >cross purposes of waiting a year for an additional allocation as that >rate would use up the block in around 4 months with 8 months or so left >in the year before eligible for another allocation. I could live with >reducing the minimum sizes but I'm guessing some won't like the effect >on the routing table to do that. I do think these changes would be >positive a whole. > >Steven L Ryerse >President >100 Ashford Center North, Suite 110, Atlanta, GA 30338 >770.656.1460 - Cell >770.399.9099 - Office >770.392-0076 - Fax > >? Eclipse Networks, Inc. > Conquering Complex Networks? > > >-----Original Message----- >From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >Behalf Of Alexander, Daniel >Sent: Sunday, July 21, 2013 11:33 PM >To: arin-ppml at arin.net >Subject: Re: [arin-ppml] Initial ISP Allocation Policy > >Hello All, > >I have submitted proposal text to facilitate this discussion. I am sure >there will be many comments and changes, but wanted to provide a >starting point. This proposal is an attempt to simplify one part of the >NRPM in a way that is easily understood even though it intentionally >leaves other parts unresolved. This was done to keep the scope to >something that could realistically be discussed. > >There is also a red-lined version of section four attached to this >email that illustrates the proposed changes. The document strikes >through the text suggested to be removed, and the suggested additions >are in bold and italicized. Everything in a standard font is pre-existing text. > >Here is a summary of the suggested requirements that would change: > >* Minimum allocation for a single-homed ISP is reduced from a /20 to /22. >* Minimum allocation for a multi-homed ISP is reduced from a /22 to a /24. >* The distinction between subscriber members who are before or after a >one year anniversary is removed. >* Minimum assignments for a single-homed end user is reduced from a /20 >to a /22. >* The requirement that multi-homed, end-user assignments smaller than a >/20 be made from a block reserved for that purpose is removed. >* The utilization requirements on an initial end-user assignment >changes from 25% immediate, 50% within one year to 80% within three >months. This is offset by the lowering of the minimum block size >requirement for single-homed networks. >* The timeframe for additional ISP allocations is changed from three >months back to one year. >* The special section for the Caribbean region is integrated into the >same requirements as the rest of the region with the existing /22 and >the addition of an option for a multi-homed /24. > >Sincerely, > >Dan Alexander >Speaking only for myself. > >On 7/18/13 12:16 PM, "Matthew Wilder" wrote: > >>Hi David, >> >>I think this is a great way of looking at. NRPM could be so much >>simpler, but in a multi-stakeholder world, we all see the tendency for >>policy changes to complicate, not simplify NRPM. The only way to >>simplify NRPM to a reasonable (sane) state is to start with a blank >>sheet of paper, as you say. Our current NRPM is just shy of 15,000 >>words. The sections which really need to be updated to accomplish >>your stated objective are section 4 and section 6, which combined >>contain >>8,356 words. In my mind a sane NRPM would have half that many words. >> >>If you constrain the efforts simply to merging any policy which >>distinguishes between End Users and ISPs, you will have around 4,000 >>words in scope. I imagine the majority of challenge faced in this >>activity will be merging section 4.2 with 4.3, with several topics >>sure to create quite the discussion (3 month allocations for ISPs vs >>12 months for End Users, Registration for downstream customers to name two). >> >>The way I could imagine finding some success in the overarching >>ambitions is to define what sections of NRPM we are interested in >>transforming, and by contrast those which we believe should stand. I >>believe that the majority of content outside section 4 and section 6 >>is reasonable enough. >> I also believe that your intent is primarily to simplify the NRPM as >>it relates to allocation of IPv4 and IPv6 resources, so likely the >>energy should naturally focus on those 2 sections. >> >>If the community is in support of re-writing those sections of NRPM, >>the two following topics should be considered for discussion (and >>possibly more I have not identified): >> >>1. Will three month allocations apply also to End-Users as it does to >>ISPs? This is going to be the biggest bone of contention as I see it, >>and the big reason why many would still see value in a distinction >>between ISP and End-User, despite lines blurring as many have observed. >>I work for an ISP, and I see the similarities of hotels, coffee shops, >>CDNs, cloud providers and so on. To what set or subset of Orgs should >>the three month allocation apply? Merging End-Users and ISPs in >>policy will be challenging here. >> >>2. What reassignments need to be registered for the global community's >>benefit in a paradigm which no longer distinguishes between ISP and >>End-User? I would suggest that static assignments of a certain size >>to entities outside the Organization specified as the resource holder >>should be registered. This mean Starbucks and the Hyatt don't have to >>register their DHCP pools used by their customers (although maybe a >>record of that DHCP would be desirable). In any case, this needs to >>be thought through at a higher level and then specifications laid out. >> >>I am certainly interested in seeing what other have to say. It may be >>very difficult to parse what can be reasonably removed from >>expectations of ISPs in order to align with End-Users, and conversely >>how happy End-Users will be to share the 3-month allocation policy >>with ISPs. If the majority of value is seen by many in simple >>alignment of initial allocation and assignment (and to some degree >>subsequent allocation / assignment), I believe the policy changes will >>be much easier to manage and build consensus around. >> >>Cheers, >>Matthew Wilder >> >> >>-----Original Message----- >>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>On Behalf Of David Huberman >>Sent: July 18, 2013 01:36 AM >>To: arin-ppml at arin.net >>Subject: Re: [arin-ppml] Initial ISP Allocation Policy >> >>Hello everyone, >> >>I would like to thank everyone for a very good discussion in this thread. >>First I'll give a very brief summary of the discussion so far, and >>then I have a solution to float to the list for feedback. >> >>Myself, Dan, Bill, and Steven have posted in favor of the high level >>concept that the differentiation in ARIN policy between enterprise >>networks and provider networks is no longer productive or relevant. >>Owen may agree in principle, but cautions us to be very careful with >>how we proceed. He is concerned that an effective "one size fits all" >>solution may be very difficult to design. George offers us an >>alternative nomenclature to consider (NSP v. ISP). >> >>I would like to now shift the discussion to how we approach >>potentially collapsing the two categories into one so that future >>interactions with ARIN are conducted under policy language which is >>relevant in 2014 and beyond. >> >>I agree with Dan that a wholesale paradigm shift in ARIN policy can >>only be accomplished with multiple proposals. There would be quite a >>few sections to change (with each change requiring careful >>consideration by the community). Moreover, I think we must be >>sensitive to ARIN's need to react to the possible impacts to both the >>financial and workflow modeling that would result from any changes we >>propose. >> >>At the same time, incremental change in NRPM is actually really hard. >>If this were 5 years ago, I would probably work very hard to help >>effect incremental change. But I think ARIN and the community have >>together failed to react to changes in the market over the last 15 >>years, and it is time to consider very big change. Let's get NRPM into >>a sane state for >>2014 and beyond. >> >>In an effort to roll up sleeves and be productive, please indulge me >>while I lay out one potential vision for what a sane NRPM might look >>like. I warn you, good reader, that some of what I propose is very >>radical. >> >>- A section on obtaining initial IPv4 addresses from ARIN. No >>distinction between end-users and ISPs. No distinction between >>single-homed and multi-homed deployments (*if you don't understand why >>the difference has no virtue, ping me on or off list and I will show >>you the math as I see it). Text might look something like: >> >> "In order to receive an initial allocation from ARIN, an organization >>must: >> >> - demonstrate they operate an IP network that requires >> IPv4 addresses to deploy and/or grow; and >> >> - provide a numbering plan detailing how IPv4 addresses >> will be used in the first 180 days upon receiving an allocation. >> >> ARIN will review and verify the data provided, and provide for the >>organization's 6 month need." >> >>- A section on obtaining additional blocks, which still outlines the >>80% rule. ("If you've efficiently used what you have, you can have >>more" is a technically sound concept that does not need much fixing.) >>Platform differences which are already fleshed out in NRPM (e.g., >>residential market area provider networks with their different metrics >>than more common buildouts) can and should remain. >> >>- We would have to figure out what to do with the requirement to SWIP, >>as the requirement is predicated on the classification of "ISP" >>actually existing (which it would not). That might need a working >>group to reconcile. >> >>- A section on obtaining initial IPv6 addresses from ARIN. Given that >>IPv6 is still very much in its infancy, I really would like to see >>very simple NRPM text which allows requestors to self-select what size >>block they need. The only barrier to abuse or silliness would be the fee >>schedule. It is arrogant and technically indefensible that ARIN policy >>today tries to dictate what a network does, and does not, justify as >>far as block size. IPv6 is much too immature for ARIN policy to >>presume such wisdom. >> >>- A section on obtaining additional IPv6 addresses from ARIN. >>Existing text in 6.5.3 is probably good enough for today, as there are >>only a handful of networks in the world with any experience needing >>additional >>IPv6 addresses due to efficient use of an initial block. Obtaining >>additional IPv6 addresses is a topic for many years from now, not today. >> >>Do you think any of this has value? Would it accomplish the >>overarching goal of improving ARIN policy to make it relevant to >>network operators in >>2014 and beyond? What would your sane NRPM look like? >> >>With regards, >>David >> >> >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to the ARIN >>Public Policy Mailing List (ARIN-PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-ppml >>Please contact info at arin.net if you experience any issues. >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to the ARIN >>Public Policy Mailing List (ARIN-PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-ppml >>Please contact info at arin.net if you experience any issues. > From bill at herrin.us Mon Jul 22 17:23:52 2013 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jul 2013 17:23:52 -0400 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <1017791891.198442.1374520338958.JavaMail.zimbra@network1.net> References: <1974582021.198115.1374515791800.JavaMail.zimbra@network1.net> <1017791891.198442.1374520338958.JavaMail.zimbra@network1.net> Message-ID: On Mon, Jul 22, 2013 at 3:12 PM, Randy Carpenter wrote: >> More, nearly all rural ISPs can contract a private point to point line >> to the nearest city with a carrier-neutral data center and pick up >> another ISP there. > > Not for anything even close to reasonable cost. We're talking 100+ miles of fiber that would have to be newly installed. Hi Randy, At the customer counts you're talking about (more than a /22, less than a /20) you can keep email and web running with a handful of T1s. Or splurge on a T3. Neither requires construction of 100 miles of new fiber. It isn't N+1 but it's a meaningful reliability enhancement for the most critical services and it qualifies you as multihomed from ARIN's perspective. >> What you mean is that they can't get a second upstream at a price >> that's viable for their customer base. > > Of course that is what I mean. If the companies I am talking about > had billions of dollars, then there would not be an issue. But, they > would also no longer be the companies I am talking about. Thousands. N+1 costs more but let's keep our eyes on the ball. To be multihomed you need thousands of dollars. Even way out in the boonies. >> At any rate, if Daniel ties the two proposals together, I'd bet he'll >> sink them both. Since the disucssion seems to focus on unifying >> registrant classes rather than reducing minimum allocations, I'd >> recommend he split the latter out. > > I agree that separate proposals may be better. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Jul 22 20:25:47 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2013 19:55:47 -0430 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: <37352D5C-D12E-4CF9-A7CA-74900222FE63@delong.com> Message-ID: <5C3EBCEA-36FE-4BDF-A7FB-19644BC8E351@delong.com> On Jul 19, 2013, at 12:38 PM, William Herrin wrote: > On Fri, Jul 19, 2013 at 10:52 AM, Owen DeLong wrote: >> 2. If you believe I am wrong about Starbucks, I suggest this experiment (yes, I have tried this): >> >> 1. Bring several devices and a router with you to Starbucks. >> 2. Connect the router to the Starbucks Wifi and use it to run a LAN for the other devices >> treating the Starbucks wifi as an upstream connection. > > http://hight3ch.com/wp-content/uploads/2008/02/starbucks_desktop.jpg > http://coolpicsbro.com/post/33014 > As near as I can tell, both of those are individual terminal hosts, not routers with networks behind them. Owen From leslien at arin.net Tue Jul 23 11:10:47 2013 From: leslien at arin.net (Leslie Nobile) Date: Tue, 23 Jul 2013 15:10:47 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: Message-ID: Hi Jon- My apologies for the late reply to your question below. Just to clarify, ARIN does consider VPS providers to be ISPs. As defined in NRPM 2.8, an end user is an organization receiving assignments of IP addresses exclusively for use in its operational networks. We interpret this to mean "for assignment exclusively to equipment/infrastructure it operates". A VPS provider assigns IP addresses to virtual servers that are operated by customers. Therefore, a VPS provider is not an end user as they are assigning IP addresses to equipment/infrastructure they don't operate. Please note that the community is currently discussing 2 policy proposals on ppml that will potentially change the definition of ISP and end user (pp 2013-5 and prop 190). Regards, Leslie Leslie Nobile Director, Registration Services American Registry for Internet Numbers On 7/17/13 6:10 PM, "Jon Daniels" wrote: >Is a VPS company an ISP or an end user? > >ARIN told me in a ticket regarding an initial IPv4 end-user request >(this is yesterday) that the virtual server (VPS) company i work for, >is NOT an end-user, but is an ISP. Each virtual servers uses less >than a /29, and we do not do SWIP, reallocate, or reassign any IP >space. The company only provides virtual servers. > > > >On Wed, Jul 17, 2013 at 2:18 PM, Owen DeLong wrote: >> >> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >> >>> On Wed, Jul 17, 2013 at 4:02 PM, Justin Krejci >>> wrote: >>>> Here is my newbie and possibly naive response. >>>> >>>> Without additional details on individual cases in the list, I would >>>>expect all of those cases to be "end-users" as none of them are in the >>>>business of reallocating address blocks. Right or wrong I've always >>>>been under the impression this to be the general rule of thumb: if >>>>allowed to reallocate then you're an ISP, else end-user; maybe to back >>>>up even further the primary purpose of the listed organizations are >>>>not to provide Internet connectivity services nor is it their primary >>>>goal or likely even a secondary goal. >>>> >>>> Akamai, provide effective access to 3rd party content >>>> Google, provide advertising, searching, and various web related >>>>services >>>> U of Maryland, provide education >>>> Starbucks, provide beverages and calories in solid form >>>> Hilton/Marriott, provide hospitality >>>> Linode, provide virtual server hosting >>>> Godaddy, provide DNS/web hosting >>>> >>>> In any case, NRPM 2.6 says, "An end-user is an organization receiving >>>> assignments of IP addresses exclusively for use in its operational >>>> networks." I think all of these example cases seem to fit this wording >>>> as they are operating their identified systems within their >>>>operational >>>> networks. >>> >>> Hi Justin, >>> >>> What about Verizon Wireless? They're primarily a cellular phone >>> company, and the overwhelming majority of the phones on which IP >>> addresses are used are still on the rent-to-own plan where you have to >>> complete the 2 year contract before you actually own the phone. Untill >>> then you're just leasing the use of their equipment. >> >> It's my understanding that it is inappropriate to name particular >>companies in this case, but the below applies equally well to $CELLCO, >>so I'll speak to that. >> >> That's not true. If you were leasing their equipment, then you could >>terminate the contract and give the equipment back to them. Instead, you >>have to reimburse them for the subsidy (and possibly more in most >>cases). You bought the phone at a reduced price. You agreed to a service >>contract in exchange for that reduced price. If you terminate the >>contract early, you are obliged to pay back said discount. That is to >>the same as leasing equipment they own. >> >>> ISP or end-user? >> >> ISP? $CELLCO generally assigns a block of addresses to the phone (at >>least my $CELLCO assigns a /64 to my phone) and should be registering >>those assignments. Further, they are also providing a service which is >>intended to provide internet access to customer-owned hardware (your >>lease argument doesn't actually hold water as stated above). Even if the >>hardware is leased, it still counts as hardware under the customer's >>control. >> >>> What about Comcast? They're in the business of providing cable >>> television service. They'll also provide you with Internet access on >>> the same coax cable with the modem they rent you. >>> >>> ISP or end-user? >> >> The service is intended to be used to connect customer-owned equipment >>to the internet. As such, they are clearly in the LIR/ISP realm. >> >> 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 info at arin.net if you experience any issues. >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. From jdaniels at forked.net Tue Jul 23 15:31:22 2013 From: jdaniels at forked.net (Jon Daniels) Date: Tue, 23 Jul 2013 12:31:22 -0700 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: Hi Leslie, Thank you for your reply. I have been following the policy proposals with interest. > A VPS provider assigns IP addresses to virtual servers that are operated > by customers. Therefore, a VPS provider is not an end user as they are > assigning IP addresses to equipment/infrastructure they don't operate. Using this interpretation, does this mean ARIN considers a web hosting provider to be an ISP? They also assign IP addresses to websites (infrastructure) that are operated exclusively by customers. Do the folks at ARIN who are making this interpretation understand that a VPS is not hardware, but software? -Jon On Tue, Jul 23, 2013 at 8:10 AM, Leslie Nobile wrote: > Hi Jon- > > My apologies for the late reply to your question below. > > Just to clarify, ARIN does consider VPS providers to be ISPs. As defined > in NRPM 2.8, an end user is an organization receiving assignments of IP > addresses exclusively for use in its operational networks. We interpret > this to mean "for assignment exclusively to equipment/infrastructure it > operates". > > A VPS provider assigns IP addresses to virtual servers that are operated > by customers. Therefore, a VPS provider is not an end user as they are > assigning IP addresses to equipment/infrastructure they don't operate. > > Please note that the community is currently discussing 2 policy proposals > on ppml that will potentially change the definition of ISP and end user > (pp 2013-5 and prop 190). > > Regards, > Leslie > > > Leslie Nobile > Director, Registration Services > American Registry for Internet Numbers > > > > > On 7/17/13 6:10 PM, "Jon Daniels" wrote: > >>Is a VPS company an ISP or an end user? >> >>ARIN told me in a ticket regarding an initial IPv4 end-user request >>(this is yesterday) that the virtual server (VPS) company i work for, >>is NOT an end-user, but is an ISP. Each virtual servers uses less >>than a /29, and we do not do SWIP, reallocate, or reassign any IP >>space. The company only provides virtual servers. >> >> >> >>On Wed, Jul 17, 2013 at 2:18 PM, Owen DeLong wrote: >>> >>> On Jul 17, 2013, at 4:34 PM, William Herrin wrote: >>> >>>> On Wed, Jul 17, 2013 at 4:02 PM, Justin Krejci >>>> wrote: >>>>> Here is my newbie and possibly naive response. >>>>> >>>>> Without additional details on individual cases in the list, I would >>>>>expect all of those cases to be "end-users" as none of them are in the >>>>>business of reallocating address blocks. Right or wrong I've always >>>>>been under the impression this to be the general rule of thumb: if >>>>>allowed to reallocate then you're an ISP, else end-user; maybe to back >>>>>up even further the primary purpose of the listed organizations are >>>>>not to provide Internet connectivity services nor is it their primary >>>>>goal or likely even a secondary goal. >>>>> >>>>> Akamai, provide effective access to 3rd party content >>>>> Google, provide advertising, searching, and various web related >>>>>services >>>>> U of Maryland, provide education >>>>> Starbucks, provide beverages and calories in solid form >>>>> Hilton/Marriott, provide hospitality >>>>> Linode, provide virtual server hosting >>>>> Godaddy, provide DNS/web hosting >>>>> >>>>> In any case, NRPM 2.6 says, "An end-user is an organization receiving >>>>> assignments of IP addresses exclusively for use in its operational >>>>> networks." I think all of these example cases seem to fit this wording >>>>> as they are operating their identified systems within their >>>>>operational >>>>> networks. >>>> >>>> Hi Justin, >>>> >>>> What about Verizon Wireless? They're primarily a cellular phone >>>> company, and the overwhelming majority of the phones on which IP >>>> addresses are used are still on the rent-to-own plan where you have to >>>> complete the 2 year contract before you actually own the phone. Untill >>>> then you're just leasing the use of their equipment. >>> >>> It's my understanding that it is inappropriate to name particular >>>companies in this case, but the below applies equally well to $CELLCO, >>>so I'll speak to that. >>> >>> That's not true. If you were leasing their equipment, then you could >>>terminate the contract and give the equipment back to them. Instead, you >>>have to reimburse them for the subsidy (and possibly more in most >>>cases). You bought the phone at a reduced price. You agreed to a service >>>contract in exchange for that reduced price. If you terminate the >>>contract early, you are obliged to pay back said discount. That is to >>>the same as leasing equipment they own. >>> >>>> ISP or end-user? >>> >>> ISP? $CELLCO generally assigns a block of addresses to the phone (at >>>least my $CELLCO assigns a /64 to my phone) and should be registering >>>those assignments. Further, they are also providing a service which is >>>intended to provide internet access to customer-owned hardware (your >>>lease argument doesn't actually hold water as stated above). Even if the >>>hardware is leased, it still counts as hardware under the customer's >>>control. >>> >>>> What about Comcast? They're in the business of providing cable >>>> television service. They'll also provide you with Internet access on >>>> the same coax cable with the modem they rent you. >>>> >>>> ISP or end-user? >>> >>> The service is intended to be used to connect customer-owned equipment >>>to the internet. As such, they are clearly in the LIR/ISP realm. >>> >>> 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 info at arin.net if you experience any issues. >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to >>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-ppml >>Please contact info at arin.net if you experience any issues. > From rcarpen at network1.net Tue Jul 23 15:39:44 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 23 Jul 2013 15:39:44 -0400 (EDT) Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: References: Message-ID: <1131281042.201889.1374608384146.JavaMail.zimbra@network1.net> I think a clear distinction can be made between a VPS, where the customer has full access to the entirety of an operating system with full root/admin access, and virtual web hosting account, where the customer likely has very little access to anything other than the ability to upload files to serve via web. I do agree there some potential grey areas emerging due to virtual/cloud/etc. -Randy ----- Original Message ----- > Hi Leslie, > > Thank you for your reply. I have been following the policy proposals > with interest. > > > A VPS provider assigns IP addresses to virtual servers that are operated > > by customers. Therefore, a VPS provider is not an end user as they are > > assigning IP addresses to equipment/infrastructure they don't operate. > > Using this interpretation, does this mean ARIN considers a web hosting > provider to be an ISP? They also assign IP addresses to websites > (infrastructure) that are operated exclusively by customers. > > Do the folks at ARIN who are making this interpretation understand > that a VPS is not hardware, but software? > > -Jon > From jcurran at arin.net Tue Jul 23 16:01:48 2013 From: jcurran at arin.net (John Curran) Date: Tue, 23 Jul 2013 20:01:48 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <1131281042.201889.1374608384146.JavaMail.zimbra@network1.net> References: <1131281042.201889.1374608384146.JavaMail.zimbra@network1.net> Message-ID: <1A5F9C8C-83A6-412A-B8D9-61281E92B36B@arin.net> On Jul 23, 2013, at 3:39 PM, Randy Carpenter wrote: > I think a clear distinction can be made between a VPS, where the customer has full access to the entirety of an operating system with full root/admin access, and virtual web hosting account, where the customer likely has very little access to anything other than the ability to upload files to serve via web. > > I do agree there some potential grey areas emerging due to virtual/cloud/etc. Indeed. One of the difficulties with different categories of policy is that it is inevitably based on past service/business models, and hence does not necessarily map well to the quickly evolving Internet. One can either enumerate specific cases or establish guidelines that are fairly general in nature. In this case, we effectively have a set of guidelines for what an end-user organization is, based on the definitions in the number resource policy manual. If folks feel that there are better criteria today as to whether an organization is an ISP vs end-user, then it would be good to propose a policy change accordingly Thanks! /John John Curran President and CEO ARIN From David.Huberman at microsoft.com Tue Jul 23 16:09:45 2013 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 23 Jul 2013 20:09:45 +0000 Subject: [arin-ppml] Initial ISP Allocation Policy In-Reply-To: <1A5F9C8C-83A6-412A-B8D9-61281E92B36B@arin.net> References: <1131281042.201889.1374608384146.JavaMail.zimbra@network1.net> <1A5F9C8C-83A6-412A-B8D9-61281E92B36B@arin.net> Message-ID: <9998b559433b464f86bd1761a1937747@BN1PR03MB250.namprd03.prod.outlook.com> John Curran wrote: > One can either enumerate specific cases or establish guidelines that > are fairly general in nature. In this case, we effectively have a set of > guidelines for what an end-user organization is, based on the definitions > in the number resource policy manual. If folks feel that there are better > criteria today as to whether an organization is an ISP vs end-user, then it > would be good to propose a policy change accordingly I think this is a good time to note that in another branch of this very same thread, we are discussing potential policy language to remove from NRPM the distinction between end-user organizations and ISPs, so as to align policy criteria ("how do I qualify for IP addresses?") with operational realities in 2014 and beyond. The language on the table this week would obviate the need for ARIN staff to answer the difficult question, "is an ISP or an end-user". With regards, David From info at arin.net Wed Jul 24 15:13:21 2013 From: info at arin.net (ARIN) Date: Wed, 24 Jul 2013 15:13:21 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2013=2E3_=96_New_Policy_Impleme?= =?windows-1252?q?nted?= Message-ID: <51F02751.30601@arin.net> On 18 June 2013 the ARIN Board of Trustees adopted the following policy: ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2013.3 is effective 24 July 2013 and supersedes the previous version. NRPM 2013.3 contains the implementation of ARIN-2012-2. ARIN-2012-2 added to the criteria under which LIRs/ISPs can qualify for subsequent allocations. The NRPM is available at: https://www.arin.net/policy/nrpm.html Board minutes are available at: https://www.arin.net/about_us/bot/index.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ ARIN-2012-2 is archived at: https://www.arin.net/policy/proposals/2012_2.html The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Jul 26 00:53:03 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 26 Jul 2013 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201307260453.r6Q4r4ml004364@rotala.raleigh.ibm.com> Total of 28 messages in the last 7 days. script run at: Fri Jul 26 00:53:03 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 4 | 44.47% | 191316 | daniel_alexander at cable.comcast.com 10.71% | 3 | 11.17% | 48067 | sryerse at eclipse-networks.com 14.29% | 4 | 6.17% | 26552 | bill at herrin.us 10.71% | 3 | 7.31% | 31462 | owen at delong.com 10.71% | 3 | 4.73% | 20363 | rcarpen at network1.net 10.71% | 3 | 4.34% | 18690 | jcurran at arin.net 7.14% | 2 | 4.65% | 19988 | david.huberman at microsoft.com 3.57% | 1 | 4.71% | 20279 | bjones at vt.edu 3.57% | 1 | 4.45% | 19164 | dave at goflashpoint.com 3.57% | 1 | 2.73% | 11750 | jdaniels at forked.net 3.57% | 1 | 2.40% | 10306 | leslien at arin.net 3.57% | 1 | 1.66% | 7150 | narten at us.ibm.com 3.57% | 1 | 1.20% | 5170 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 28 |100.00% | 430257 | Total From farmer at umn.edu Mon Jul 29 09:01:47 2013 From: farmer at umn.edu (David Farmer) Date: Mon, 29 Jul 2013 08:01:47 -0500 Subject: [arin-ppml] Fwd: BCP 6, RFC 6996 on Autonomous System (AS) Reservation for Private Use In-Reply-To: <20130729101405.2250E6210F@rfc-editor.org> References: <20130729101405.2250E6210F@rfc-editor.org> Message-ID: <51F667BB.3050809@umn.edu> I mentioned the Draft this RFC is based on in a previous email thread. Also, I think this RFC is of general interest to the ARIN Community and while not directly a policy issue, it is related to the overall management of Autonomous System Numbers (ASNs). Thanks -------- Original Message -------- Subject: BCP 6, RFC 6996 on Autonomous System (AS) Reservation for Private Use Date: Mon, 29 Jul 2013 03:14:05 -0700 (PDT) From: rfc-editor at rfc-editor.org Reply-To: ietf at ietf.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: drafts-update-ref at iana.org, idr at ietf.org, rfc-editor at rfc-editor.org A new Request for Comments is now available in online RFC libraries. BCP 6 RFC 6996 Title: Autonomous System (AS) Reservation for Private Use Author: J. Mitchell Status: Best Current Practice Stream: IETF Date: July 2013 Mailbox: Jon.Mitchell at microsoft.com Pages: 4 Characters: 8198 Updates: RFC 1930 See Also: BCP 6 I-D Tag: draft-ietf-idr-as-private-reservation-05.txt URL: http://www.rfc-editor.org/rfc/rfc6996.txt This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document. This document is a product of the Inter-Domain Routing Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC