From info at arin.net Wed Sep 2 09:14:21 2009 From: info at arin.net (Member Services) Date: Wed, 02 Sep 2009 09:14:21 -0400 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out In-Reply-To: <4A9BEEB1.2070708@arin.net> References: <4A9BEEB1.2070708@arin.net> Message-ID: <4A9E6FAD.7030801@arin.net> Correction; there was a typo in the url. Draft Policy 2009-8 can be found at: https://www.arin.net/policy/proposals/2009_8.html Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > Draft Policy 2009-8 > Equitable IPv4 Run-Out > > On 20 August 2009 the ARIN Advisory Council (AC) selected "Equitable > IPv4 Run-Out" as a draft policy for adoption discussion on the PPML and > at the Public Policy Meeting in Dearborn. > > The draft was developed by the AC from Policy Proposals "93: Predicable > IPv4 Run Out by Prefix Size and 94: Predictable IPv4 Run Out by > Allocation Window". Per the Policy Development Process the AC submitted > text to ARIN for a staff and legal assessment prior to its selection as > a draft policy. After reviewing the assessment the AC made several > changes to the text. > > Draft Policy 2009-8 is below and can be found at: > https://www.arin.net/policy/proposals/2009_8.htm > > Below the draft policy is the ARIN staff and legal assessment, including > the original proposal text. > > You are encouraged to discuss Draft Policy 2009-8 on the PPML prior to > the October Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-8 > Equitable IPv4 Run-Out > > Version/Date: 31 August 2009 > > Policy statement: > > Replace NRPM 4.2.4.4 with; > > 4.2.4.4 Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one year, > they may choose to request up to a 12 month supply of IP addresses. > > As the IANA free pool decreases, the length of supply that an > organization may request will be reduced at the following thresholds. > This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12 month supply of IP addresses. > > When IANA reaches 20 or fewer unallocated /8s, an organization may > choose to request up to a 6 month supply of IP addresses; > > When IANA reaches 10 or fewer unallocated /8s, an organization may > choose to request up to a 3 month supply of IP addresses; > > Create a new subsection in section 4 of the NRPM; > > 4.X Maximum Allocation or Assignment during and following Run-Out > > When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a > proportionally decreasing maximum allocation, and assignment, size will > be put into effect. The maximum allocation will be the next whole CIDR > prefix less than or equal to one quarter (1/4) of the total ARIN free > pool available at the time of each allocation, but no longer than the > applicable minimum allocation. > > An organization may request additional resources when it can demonstrate > it has properly utilized all previous allocations per applicable > policies. However, the total of all allocations received within the last > three (3) month period and the current request, cannot exceed the > current maximum allocation size. > > This maximum allocation size is applicable to allocations from the ARIN > free pool only. It is explicitly not applicable to resources received > via transfer under section 8.3, or any other specially designated > resources. > > Rationale: > > This proposed policy is intended to ensure an equitable distribution of > IPv4 resources as run-out of the IANA free pool and subsequently the > ARIN free pool occurs. This is achieved in two parts; first, changing > section 4.2.4.4 of the NRPM to reduce the length of supply of IPv4 > resources that may be requested in steps as the IANA free pool runs-out. > This helps accomplish equity by reducing the window that an advantage or > disadvantage can exist between competitors, that will be created when > one competitor receives a final allocation just before run-out and > another competitor does not. > > The reductions in the length of supply will be triggered by IANA > reaching defined levels of unallocated /8s, including the /8s reserved > as part of section 10.4 of the NRPM. These triggers have been chosen > base on the current rate of consumption of /8s by the RIRs. > > The first part of this policy is similar to ideas in RIPE policy > proposal 2009-03 > (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been > adapted by discussion and for use within the ARIN region. > > The second part of this policy, allows a maximum of one quarter (1/4) of > the then current total IPv4 resources to be allocated in a single > request, once ARIN has received its last /8 from IANA. This helps > achieve equity by ensuring the available resources are spread among > multiple organizations and that no single organization may monopolize > all of the resources available through a single request, at least until > the maximum allocation size has been reduced down to the minimum > allocation size. > > Incrementally reducing the length of supply and then reducing the > maximum allocation size in proportion to the amount of resources > available should minimize, or possibly eliminate, the need to fulfill > requests with multiple smaller blocks. > > As in the current NRPM, the length of supply only applies to ISP > allocations. However, the maximum allocation size is intended to apply > to both ISP allocations and End-user assignments. > > This policy is intended to be independent of other policies or proposals > to reserve address space for IPv6 transition or other purposes. Neither > part is intended to limit Transfers to Specified Recipients per section > 8.3 of the NRPM. > > The current maximum allocation size should be published on the ARIN > website, preferably in real-time, as it may change rapidly as the ARIN > free pool resources are exhausted. In the worst-case the maximum > allocation size will decrease every forth allocation, when all four are > the then current maximum allocation size. However, in the beginning > there will likely be many smaller allocations before the maximum > allocation size is decreased, accelerating as the resources are > exhausted. > > Following the run-out phase, this policy provides an equitable means of > distribution of resources if or when additional resources become > available after ARIN has initially exhausted such resources. Such as if > resources are returned, recovered by other means, or additional > resources are obtained from IANA. Further, whenever ARIN receives a > sufficiently large amount of additional resources, this policy intends > for the maximum allocation size to be increased accordingly. > > After ARIN receives its last /8, the intent is to normally limit an > organization to a single maximum allocation within a three month period. > However, saying it that simply opens this policy to gamesmanship in > requesting less than a maximum allocation. Requiring a maximum > allocation to cover new requests and all allocations received in the > previous three month period, should eliminate this kind of gamesmanship. > > There is a beneficial side effect of stating it this way, in the special > situation when the maximum allocation size is increased, due to ARIN > obtaining a sufficiently large amount of additional resources, an > organization may receive additional resources earlier than the normal > three month period. But, only in this special situation and when an > organization properly utilizes a previous maximum allocation in less > than three months, may an organization receive additional resources in > less than the normal three month period. > > Other ratios, such as one half (1/2) or one eighth (1/8) could be > considered. One eighth (1/8) would provide greater assurance of > eliminating the need to use multiple blocks to fulfill requests and > ensure a greater number of organizations receive resources. However, one > eighth (1/8) is more likely to be seen as rationing and an attempt to > artificially extend the lifetime of IPv4. During the ARIN XXIII policy > discussion there seemed to be a consensus that attempts to extend the > lifetime of IPv4 resources would be undesirable. While on the other > hand, one half (1/2) is even less likely to ration resources, but it > would likely result in the resource being spread across significantly > fewer organizations and increase the need to use multiple blocks to > fulfill requests. > > In conclusion, combining the final 3 month length of supply with the one > quarter (1/4) ratio provides roughly an annualized equivalent of the > whole ARIN free pool being made available to a single organization. > While it is not possible for a single organization to receive the whole > ARIN free pool within one year under this policy, it is a virtual > certainty that multiple organization will be requesting resources, and > that the ARIN free pool will not likely last a full year following the > exhaustion of the IANA free pool anyway. Therefore, the ratio one > quarter (1/4) seems to strike a balance between making resources > available with as little restriction as possible and ensuring an > equitable distribution of those resources during and following the > run-out phase. > > EDITORIAL NOTE: This Draft Policy 2009-8 merges ideas from two separate > policy proposals, 93. Predicable IPv4 Run Out by Prefix Size and 94. > Predictable IPv4 Run Out by Allocation Window. > > Timetable for implementation: Immediate > > ##### > ##### > > Proposal: Equitable IPv4 Run-Out > > Proposal Version (Date): 3 August 2009 > > Date of Assessment: 18 August 2009 > > 1. Proposal Summary (Staff Understanding) > Staff understands the policy applies to ISPs who have been ARIN members > for more than a year. When IANA reaches 20 /8s, the supply period for > IPv4 address space will decrease from a 12 months to 6 months. When the > IANA reaches 10 or less /8s, the supply period is reduced to 3 months. > The second part of the proposal triggers upon receipt of ARIN?s last /8 > from the IANA (per NRPM 10.4.2.2). The policy would establish a new > maximum prefix size for all requests and place a limit on the amount of > space an organization can receive within any three month period. The > maximum prefix size would be on a sliding scale relative to the total > amount of free IPv4 addresses in ARIN's inventory (one fourth of the > total rounded down to the nearest smallest CIDR prefix). These polices > do not apply to Transfers to Specified Recipients (NRPM 8.3). > > 2. Comments > > A. ARIN Staff Comments > > The policy can be implemented as written. > > The title of section 4.2.4.4 needs to change from ?Twelve Months? to > ?Subscriber Members After One Year?. > > Note that the maximum prefix size in effect at any given time (e.g. > /16) may be larger than the largest available contiguous address block > in ARIN?s inventory (e.g. /18). In order to fulfill a request in this > scenario, ARIN would have to issue several discontiguous address blocks. > > There is a suggestion in the rationale to display the maximum prefix > size in real time. But that prefix size might not be available upon > completion of a request. Example, on Friday we display /18. By the time > the request is finalized, the maximum is a /19, and that?s what is > issued to the customer. We could put a disclaimer that the actual > prefix issued to a customer could be smaller. Also, we see value in > keeping track of the maximum prefix size over time. > > The third sentence of the proposed 4.2.4.4 (starting with "This > reduction") is a run-on sentence and contains grammatical errors. ARIN > staff suggests the following replacement text: ?This reduction does not > apply to resources received via section 8.3. Organizations requesting > transfers under 8.3 may choose to request up to a 12-month supply of IP > addresses.? > > B. ARIN General Counsel > > ARIN has the legal duty and authority to establish more restrictive > rules to ?ration? the issuance of IPv4 resources as the scarcity of such > resources increases. However, such rules must make clear rational sense > given current circumstances, and may be tested in litigation by > disappointed parties at the time they come fully into effect, not when > adopted. Therefore, the proposed policy here will need to be carefully > reviewed and if passed, carefully implemented, for example, to prevent > any ?side effect? that would inadvertently favor one set of ISPs over > another. > > 3. Resource Impact > > This policy would have minimal resource impact. It is estimated that > implementation would occur within 3 months after ratification by the > ARIN Board of Trustees. The following would be needed in order to > implement: > Updates to software > Updated guidelines > Staff training > > 4. Proposal Text > > Equitable IPv4 Run-Out > > Date: 3 August 2009 > > Policy statement: > > Replace the text in NRPM 4.2.4.4 with; > > After an organization has been a subscriber member of ARIN for one year, > they may choose to request up to a 12 month supply of IP addresses. As > the IANA free pool decreases, the length of supply that an organization > may request will be reduced at the following thresholds. This reduction > does not apply to resources received via Transfers to Specified > Recipients per section 8.3, in this case an organization may continue > choose to request up to a 12 month supply of IP addresses. > > When IANA reaches 20 or fewer unallocated /8s , an organization may > choose to request up to a 6 month supply of IP addresses; > > When IANA reaches 10 or fewer unallocated /8s , an organization may > choose to request up to a 3 month supply of IP addresses; > > Create a new subsection in section 4 of the NRPM; > > 4.X Maximum Allocation or Assignment during and following Run-Out > > When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a > proportionally decreasing maximum allocation, and assignment, size will > be put into effect. The maximum allocation will be the next whole CIDR > prefix less than or equal to one quarter (1/4) of the total ARIN free > pool available at the time of each allocation, but no longer than the > applicable minimum allocation. An OrgID may request additional resources > when it can demonstrate it has properly utilized all previous > allocations per applicable policies. However, the total of all > allocations received within the last three (3) month period and the > current request, cannot exceed the current maximum allocation size. > This maximum allocation size is applicable to allocations from the ARIN > free pool only, and is explicitly not applicable to resources received > through Transfers to Specified Recipients per section 8.3, or any other > specially designated resources. > > Rationale: > > This proposed policy is intended to ensure an equitable distribution of > IPv4 resources as run-out of the IANA free pool and subsequently the > ARIN free pool occurs. This is achieved in two parts; first, changing > section 4.2.4.4 of the NRPM to reduce the length of supply of IPv4 > resources that may be requested in steps as the IANA free pool runs-out. > This helps accomplish equity by reducing the window that an advantage or > disadvantage can exist between competitors, that will be created > when one competitor receives a final allocation just before run-out and > another competitor does not. > > The reductions in the length of supply will be triggered by IANA > reaching defined levels of unallocated /8s, including the /8s reserved > as part of section 10.4 of the NRPM. These triggers have been chosen > base on the current rate of consumption of /8s by the RIRs. > > The first part of this policy is similar to ideas in RIPE policy > proposal 2009-03 > (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been > adapted by discussion and for use within the ARIN region. > > The second part of this policy, allows a maximum of one quarter (1/4) of > the then current total IPv4 resources to be allocated in a single > request, once ARIN has received its last /8 from IANA. This helps > achieve equity by ensuring the available resources are spread among > multiple organizations and that no single organization may monopolize > all of the resources available through a single request, at least > until the maximum allocation size has been reduced down to the minimum > allocation size. > > Incrementally reducing the length of supply and then reducing the > maximum allocation size in proportion to the amount of resources > available should minimize, or possibly eliminate, the need to fulfill > requests with multiple smaller blocks. > > As in the current NRPM, the length of supply only applies to ISP > allocations. However, the maximum allocation size is intended to apply > to both ISP allocations and End-user assignments. > > This policy is intended to be independent of other policies or proposals > to reserve address space for IPv6 transition or other purposes. Neither > part is intended to limit Transfers to Specified Recipients per section > 8.3 of the NRPM. > > The current maximum allocation size should be published on the ARIN > website, preferably in real-time, as it may change rapidly as the ARIN > free pool resources are exhausted. In the worst-case the maximum > allocation size will decrease every forth allocation, when all four are > the then current maximum allocation size. However, in the beginning > there will likely be many smaller allocations before the maximum > allocation size is decreased, accelerating as the resources are > exhausted. > > Following the run-out phase, this policy provides an equitable means of > distribution of resources if or when additional resources become > available after ARIN has initially exhausted such resources. Such as if > resources are returned, recovered by other means, or additional > resources are obtained from IANA. Further, whenever ARIN receives a > sufficiently large amount of additional resources, this policy > intends for the maximum allocation size to be increased accordingly. > > After ARIN receives its last /8, the intent is to normally limit an > organization to a single maximum allocation within a three month period. > However, saying it that simply opens this policy to gamesmanship in > requesting less than a maximum allocation. Requiring a maximum > allocation to cover new requests and all allocations received in the > previous three month period, should eliminate this kind > of gamesmanship. > > There is a beneficial side effect of stating it this way, in the special > situation when the maximum allocation size is increased, due to ARIN > obtaining a sufficiently large amount of additional resources, an > organization may receive additional resources earlier than the normal > three month period. But, only in this special situation and > when an organization properly utilizes a previous maximum allocation in > less than three months, may an organization receive additional resources > in less than the normal three month period. > > Other ratios, such as one half (1/2) or one eighth (1/8) could be > considered. One eighth (1/8) would provide greater assurance of > eliminating the need to use multiple blocks to fulfill requests and > ensure a greater number of organizations receive resources. However, one > eighth (1/8) is more likely to be seen as rationing and an attempt to > artificially extend the lifetime of IPv4. During the ARIN XXIII policy > discussion there seemed to be a consensus that attempts to extend the > lifetime of IPv4 resources would be undesirable. While on the other > hand, one half (1/2) is even less likely to ration resources, but it > would likely result in the resource being spread across significantly > fewer organizations and increase the need to use multiple blocks > to fulfill requests. > > In conclusion, combining the final 3 month length of supply with the one > quarter (1/4) ratio provides roughly an annualized equivalent of the > whole ARIN free pool being made available to a single organization. > While it is not possible for a single organization to receive the whole > ARIN free pool within one year under this policy, it is a virtual > certainty that multiple organization will be requesting resources, and > that the ARIN free pool will not likely last a full year following the > exhaustion of the IANA free pool anyway. Therefore, the ratio one > quarter (1/4) seems to strike a balance between making resources > available with as little restriction as possible and ensuring an > equitable distribution of those resources during and following the > run-out phase. > > EDITORIAL NOTE: This Draft Policy 2009-X merges ideas from two separate > policy proposals, 93. Predicable IPv4 Run Out by Prefix Size and 94. > Predictable IPv4 Run Out by Allocation Window. > > Timetable for implementation: Immediate > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From sethm at rollernet.us Wed Sep 2 12:40:09 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 02 Sep 2009 09:40:09 -0700 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: <4A9BEE9A.2000405@arin.net> References: <4A9BEE9A.2000405@arin.net> Message-ID: <4A9E9FE9.5010001@rollernet.us> Member Services wrote: > > Draft Policy 2009-7 > Open Access To IPv6 > > Version/Date: 31 August 2009 > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. > > Rationale: > > It is acknowledged that these concepts have been put before the > community in the past. However, with the wisdom of actual operational > experience, the necessity of promoting IPv6 adoption throughout our > region, and emerging native v6 only network models, it becomes obvious > that these modifications to the NRPM are necessary. Removing the 200 end > site requirement enables smaller, but no less important and viable, > networks access to IPv6. Removing the ?known ISP? requirement > enfranchises new, native v6 businesses that can drive innovation and > expansion in the Internet industry, as well as other industries. > Removing the requirement for a single aggregate announcement benefits > the NRPM itself, as it has been decided by the community that it should > not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > ##### > ##### > > Staff Assessment > > Proposal: Open Access to IPv6 (proposal #90) > > Proposal Version (Date) 21 May 2009 > > Date Assessment Due: 05 Aug 2009 > > 1. Proposal Summary (Staff Understanding) > > This policy proposal would modify NRPM section 6.5.1.1 by removing all > or part of two initial criteria from the the existing IPv6 policy: the > requirement to advertise the single aggregate and the requirement to > plan on making 200 end site assignments to customers or be a known ISP > in the ARIN region. The only remaining criteria to qualify for an IPv6 > allocation are to be an LIR/ISP, not be an end site, and plan on > providing IPv6 connectivity to organizations and assigning them IPv6 > address space. > I SUPPORT this policy. If there is concern of gaming/abusing this, then I suggest adding a clause requiring an existing IPv4 number resource from ARIN in order to obtain your /32. -- Seth Mattinen sethm at rollernet.us Roller Network LLC From msackett at verilan.com Wed Sep 2 12:49:45 2009 From: msackett at verilan.com (Morgan Sackett) Date: Wed, 2 Sep 2009 09:49:45 -0700 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: <4A9E9FE9.5010001@rollernet.us> References: <4A9BEE9A.2000405@arin.net> <4A9E9FE9.5010001@rollernet.us> Message-ID: I think adding this sort of requirement is disadvantageous to newer small networks trying to obtain IP space, especially those looking to do IPv6 only. It will also force the policy to require modification as the available v4 space runs out. On Sep 2, 2009, at 9:40 AM, Seth Mattinen wrote: > Member Services wrote: >> >> Draft Policy 2009-7 >> Open Access To IPv6 >> >> Version/Date: 31 August 2009 >> >> Policy statement: >> >> 1) Remove ?by advertising that connectivity through its single >> aggregated address allocation? from article 3 of section 6.5.1.1 >> >> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in >> the ARIN region or have a plan for making at least 200 end-site >> assignments to other organizations within 5 years? in its entirety. >> >> Rationale: >> >> It is acknowledged that these concepts have been put before the >> community in the past. However, with the wisdom of actual operational >> experience, the necessity of promoting IPv6 adoption throughout our >> region, and emerging native v6 only network models, it becomes >> obvious >> that these modifications to the NRPM are necessary. Removing the >> 200 end >> site requirement enables smaller, but no less important and viable, >> networks access to IPv6. Removing the ?known ISP? requirement >> enfranchises new, native v6 businesses that can drive innovation and >> expansion in the Internet industry, as well as other industries. >> Removing the requirement for a single aggregate announcement benefits >> the NRPM itself, as it has been decided by the community that it >> should >> not contain routing advice. >> >> Timetable for implementation: immediately upon BoT ratification >> >> ##### >> ##### >> >> Staff Assessment >> >> Proposal: Open Access to IPv6 (proposal #90) >> >> Proposal Version (Date) 21 May 2009 >> >> Date Assessment Due: 05 Aug 2009 >> >> 1. Proposal Summary (Staff Understanding) >> >> This policy proposal would modify NRPM section 6.5.1.1 by removing >> all >> or part of two initial criteria from the the existing IPv6 policy: >> the >> requirement to advertise the single aggregate and the requirement to >> plan on making 200 end site assignments to customers or be a known >> ISP >> in the ARIN region. The only remaining criteria to qualify for an >> IPv6 >> allocation are to be an LIR/ISP, not be an end site, and plan on >> providing IPv6 connectivity to organizations and assigning them IPv6 >> address space. >> > > I SUPPORT this policy. > > If there is concern of gaming/abusing this, then I suggest adding a > clause requiring an existing IPv4 number resource from ARIN in order > to > obtain your /32. > > -- > Seth Mattinen sethm at rollernet.us > Roller Network LLC > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. Morgan Sackett VP of Engineering VeriLAN Event Services, Inc. 215 SE Morrison Street Portland, OR 97214 Tel: 503 907-1415 Fax: 503 224-8833 msackett at verilan.com www.verilan.com This e-mail contains proprietary information and may be confidential. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you received this message in error, please delete it immediately. From ipgoddess.arin at gmail.com Wed Sep 2 14:20:28 2009 From: ipgoddess.arin at gmail.com (Stacy Hughes) Date: Wed, 2 Sep 2009 11:20:28 -0700 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: References: <4A9BEE9A.2000405@arin.net> <4A9E9FE9.5010001@rollernet.us> Message-ID: <24c86a5f0909021120j75a71a53mf93e874f733434cf@mail.gmail.com> Hey Seth,I purposely left that out because there really are green field v6 networks that would not otherwise qualify for an allocation. (props again to Jordi!) It seems to me the $$ required to get a v6 allocation, and the gear to run it, if you don't already have v4 is enough to prohibit gaming the system. Thanks! Stacy On Wed, Sep 2, 2009 at 9:49 AM, Morgan Sackett wrote: > I think adding this sort of requirement is disadvantageous to newer small > networks trying to obtain IP space, especially those looking to do IPv6 > only. It will also force the policy to require modification as the > available v4 space runs out. > > > On Sep 2, 2009, at 9:40 AM, Seth Mattinen wrote: > > Member Services wrote: >> >>> >>> Draft Policy 2009-7 >>> Open Access To IPv6 >>> >>> Version/Date: 31 August 2009 >>> >>> Policy statement: >>> >>> 1) Remove ?by advertising that connectivity through its single >>> aggregated address allocation? from article 3 of section 6.5.1.1 >>> >>> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in >>> the ARIN region or have a plan for making at least 200 end-site >>> assignments to other organizations within 5 years? in its entirety. >>> >>> Rationale: >>> >>> It is acknowledged that these concepts have been put before the >>> community in the past. However, with the wisdom of actual operational >>> experience, the necessity of promoting IPv6 adoption throughout our >>> region, and emerging native v6 only network models, it becomes obvious >>> that these modifications to the NRPM are necessary. Removing the 200 end >>> site requirement enables smaller, but no less important and viable, >>> networks access to IPv6. Removing the ?known ISP? requirement >>> enfranchises new, native v6 businesses that can drive innovation and >>> expansion in the Internet industry, as well as other industries. >>> Removing the requirement for a single aggregate announcement benefits >>> the NRPM itself, as it has been decided by the community that it should >>> not contain routing advice. >>> >>> Timetable for implementation: immediately upon BoT ratification >>> >>> ##### >>> ##### >>> >>> Staff Assessment >>> >>> Proposal: Open Access to IPv6 (proposal #90) >>> >>> Proposal Version (Date) 21 May 2009 >>> >>> Date Assessment Due: 05 Aug 2009 >>> >>> 1. Proposal Summary (Staff Understanding) >>> >>> This policy proposal would modify NRPM section 6.5.1.1 by removing all >>> or part of two initial criteria from the the existing IPv6 policy: the >>> requirement to advertise the single aggregate and the requirement to >>> plan on making 200 end site assignments to customers or be a known ISP >>> in the ARIN region. The only remaining criteria to qualify for an IPv6 >>> allocation are to be an LIR/ISP, not be an end site, and plan on >>> providing IPv6 connectivity to organizations and assigning them IPv6 >>> address space. >>> >>> >> I SUPPORT this policy. >> >> If there is concern of gaming/abusing this, then I suggest adding a >> clause requiring an existing IPv4 number resource from ARIN in order to >> obtain your /32. >> >> -- >> Seth Mattinen sethm at rollernet.us >> Roller Network LLC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > Morgan Sackett > VP of Engineering > > VeriLAN Event Services, Inc. > 215 SE Morrison Street > Portland, OR 97214 > > Tel: 503 907-1415 > Fax: 503 224-8833 > > msackett at verilan.com > www.verilan.com > > > This e-mail contains proprietary information and may be confidential. If > you are not the intended recipient of this e-mail, you are hereby notified > that any dissemination, distribution or copying of this message is strictly > prohibited. If you received this message in error, please delete it > immediately. > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 stephen at sprunk.org Wed Sep 2 17:01:22 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 02 Sep 2009 16:01:22 -0500 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: References: <4A9BEE9A.2000405@arin.net> <4A9E9FE9.5010001@rollernet.us> Message-ID: <4A9EDD22.7040600@sprunk.org> Morgan Sackett wrote: > On Sep 2, 2009, at 9:40 AM, Seth Mattinen wrote: >> Member Services wrote: >>> 1. Proposal Summary (Staff Understanding) >>> >>> This policy proposal would modify NRPM section 6.5.1.1 by removing >>> all or part of two initial criteria from the the existing IPv6 >>> policy: the requirement to advertise the single aggregate and the >>> requirement to plan on making 200 end site assignments to customers >>> or be a known ISP in the ARIN region. The only remaining criteria to >>> qualify for an IPv6 allocation are to be an LIR/ISP, not be an end >>> site, and plan on providing IPv6 connectivity to organizations and >>> assigning them IPv6 address space. >> >> I SUPPORT this policy. >> >> If there is concern of gaming/abusing this, then I suggest adding a >> clause requiring an existing IPv4 number resource from ARIN in order to >> obtain your /32. > I think adding this sort of requirement is disadvantageous to newer > small networks trying to obtain IP space, especially those looking to > do IPv6 only. It will also force the policy to require modification > as the available v4 space runs out. > I agree on the above-proposed modification for the same reason; the cure is worse than the disease. That said, though, I must OPPOSE the original (i.e. unmodified as above) proposal because I think that an operator without even a "plan" for making N assignments and/or who will not be advertising an aggregate for their allocation should not qualify. I might accept lowering N, if someone can present a specific example of an org which has not qualified because 200 customers is not reasonable for its circumstances, but I cannot support any proposal that removes the bar entirely and/or removes the aggregation requirement. It's bad enough that we only require a "plan", which is easily BSed, though at least 2007-14 implements consequences five years down the road if the plan has not resulted in N customers by that time. (This also shows the problem with having two or more orthogonal policy changes in a single proposal.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From bill at herrin.us Wed Sep 2 17:28:22 2009 From: bill at herrin.us (William Herrin) Date: Wed, 2 Sep 2009 17:28:22 -0400 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: <4A9BEE9A.2000405@arin.net> References: <4A9BEE9A.2000405@arin.net> Message-ID: <3c3e3fca0909021428g2d8a4afbye0774275245db8f5@mail.gmail.com> On Mon, Aug 31, 2009 at 11:39 AM, Member Services wrote: > Draft Policy 2009-7 > Open Access To IPv6 > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. I SUPPORT this proposal. Long-term concerns about the impact on the routing table qualify as a "nice problem to have." If IPv6 doesn't get itself launched to a point where its useful to the general public then we won't have any problems with the long term impact on the routing table because we won't have IPv6. At the current lethargic rate of IPv6 uptake, the immediate $560 fee and long-term expectation of a $2250/year fee is more than enough to dissuade extraneous requests. When that changes, we can implement a more restrictive policy. Perhaps we can put a safety valve on the proposal so that if by some bizarre happenstance 10,000 IPv6 /32 allocations happen without further updates to the policy, the two removed lines are restored. 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 Wed Sep 2 17:58:22 2009 From: farmer at umn.edu (David Farmer) Date: Wed, 02 Sep 2009 16:58:22 -0500 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out In-Reply-To: <4A9BEEB1.2070708@arin.net> References: <4A9BEEB1.2070708@arin.net> Message-ID: <4A9EEA7E.3010609@umn.edu> Member Services wrote: > Policy statement: > > Replace NRPM 4.2.4.4 with; > > 4.2.4.4 Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one year, > they may choose to request up to a 12 month supply of IP addresses. > > As the IANA free pool decreases, the length of supply that an > organization may request will be reduced at the following thresholds. > This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12 month supply of IP addresses. > > When IANA reaches 20 or fewer unallocated /8s, an organization may > choose to request up to a 6 month supply of IP addresses; > > When IANA reaches 10 or fewer unallocated /8s, an organization may > choose to request up to a 3 month supply of IP addresses; > 2. Comments > > A. ARIN Staff Comments > > The policy can be implemented as written. > > The title of section 4.2.4.4 needs to change from ?Twelve Months? to > ?Subscriber Members After One Year?. I addresses this Staff comment and made the change they suggested to the title of section 4.2.4.4, along with several others changes, before the final revision was voted on by the AC and went out as a Draft policy. While it didn't really change the intent, I felt the new title was much more descriptive. However, this raised a question for me personally, shouldn't we also change the title of 4.2.4.3 to something more descriptive too? Since this was not directly pertinent to this policy issue I decided to leave it out for now, feeling it could be added once we discussed this as a Draft Policy on PPML or possibly even as late as Last Call if it is necessary as it would likely only be an editorial change that wasn't changing the intent of this policy or the NRPM as a whole. From the current NRPM; ---- 4.2.4.3. Three months Provide detailed information showing specifically that the address space will be utilized within three months. Determination of the appropriate allocation to be issued is based on efficient utilization of space within this three-month time frame. 4.2.4.4. Twelve months After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses. ---- For the full context of the current NRPM Section 4.2.4 see the following link; https://www.arin.net/policy/nrpm.html#four24 So should 4.2.4.3 get a more descriptive title too, other than just "Three months"? Any suggestions on what it should be? Should such a change be included in this Draft Policy? If not, and you think it should be changed, then how should we go about it? If we want such a change included in the formal text to be discussed at Dearborn we need to finalize the text for the change by the first few days of October to give the AC and Staff a little process time before the deadline to freeze the text 10 days before the PPM. So, we have about a month or so, if we want to go that route. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From steve at ibctech.ca Thu Sep 3 08:54:12 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 03 Sep 2009 08:54:12 -0400 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: <3c3e3fca0909021428g2d8a4afbye0774275245db8f5@mail.gmail.com> References: <4A9BEE9A.2000405@arin.net> <3c3e3fca0909021428g2d8a4afbye0774275245db8f5@mail.gmail.com> Message-ID: <4A9FBC74.1060907@ibctech.ca> William Herrin wrote: > On Mon, Aug 31, 2009 at 11:39 AM, Member Services wrote: >> Draft Policy 2009-7 >> Open Access To IPv6 >> >> Policy statement: >> >> 1) Remove ?by advertising that connectivity through its single >> aggregated address allocation? from article 3 of section 6.5.1.1 >> >> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in >> the ARIN region or have a plan for making at least 200 end-site >> assignments to other organizations within 5 years? in its entirety. > > I SUPPORT this proposal. I do too. > Perhaps we can put a safety valve on the proposal so that if by some > bizarre happenstance 10,000 IPv6 /32 allocations happen without > further updates to the policy, the two removed lines are restored. ...and I also think that some form of clause such as Bill's above, allowing emergency automatic reinsertion of restrictions like this is a reasonable compromise, between those who want the restrictions, and those that don't. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From sethm at rollernet.us Thu Sep 3 11:31:40 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 03 Sep 2009 08:31:40 -0700 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: <24c86a5f0909021120j75a71a53mf93e874f733434cf@mail.gmail.com> References: <4A9BEE9A.2000405@arin.net> <4A9E9FE9.5010001@rollernet.us> <24c86a5f0909021120j75a71a53mf93e874f733434cf@mail.gmail.com> Message-ID: <4A9FE15C.4040202@rollernet.us> Stacy Hughes wrote: > Hey Seth, > I purposely left that out because there really are green field v6 > networks that would not otherwise qualify for an allocation. (props > again to Jordi!) > It seems to me the $$ required to get a v6 allocation, and the gear to > run it, if you don't already have v4 is enough to prohibit gaming the > system. > Thanks! > Stacy > I support it either way; just giving both sides their due. ~Seth From stephen at sprunk.org Thu Sep 3 13:04:03 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 03 Sep 2009 12:04:03 -0500 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 In-Reply-To: <4A9FBC74.1060907@ibctech.ca> References: <4A9BEE9A.2000405@arin.net> <3c3e3fca0909021428g2d8a4afbye0774275245db8f5@mail.gmail.com> <4A9FBC74.1060907@ibctech.ca> Message-ID: <4A9FF703.8050206@sprunk.org> Steve Bertrand wrote: > William Herrin wrote: > >> Perhaps we can put a safety valve on the proposal so that if by some bizarre happenstance 10,000 IPv6 /32 allocations happen without further updates to the policy, the two removed lines are restored. >> > > ...and I also think that some form of clause such as Bill's above, allowing emergency automatic reinsertion of restrictions like this is a reasonable compromise, between those who want the restrictions, and those that don't. > In theory, the BoT can add whatever "emergency" policies it deems necessary, so such a statement is superfluous. However, history (not specifically ARIN but in general, e.g. 1930s Germany) tells us that we should do everything possible to avoid encouraging the use of "emergency powers" lest it become a habit. That path leads to the Dark Side(tm). Therefore, I object to removing policy language from the NRPM with the assumption that the BoT will magically reinsert it at some point in the future. If we want this to be at the BoT's discretion, better to simply write a proposal that says the BoT can waive the relevant policy section(s) under some condition, e.g. until there are 10k IPv6 routes, but leave them there so they will be reinstated by default when the waiver ends. (And I'm against the BoT having such discretion; I'm just pointing out the IMHO correct way of implementing that bad idea.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From info at arin.net Thu Sep 3 15:47:01 2009 From: info at arin.net (Member Services) Date: Thu, 03 Sep 2009 15:47:01 -0400 Subject: [arin-ppml] =?windows-1252?q?2008-7=3A_Identify_Invalid_WHOIS_POC?= =?windows-1252?q?=92s_-_Adopted?= Message-ID: <4AA01D35.3080400@arin.net> On 1 July 2009 the ARIN Board of Trustees adopted the following policy: 2008-7: Identify Invalid WHOIS POC?s 2008-7 had been recommended for adoption to the Board by the ARIN Advisory Council on 21 May 2009. The implementation of 2008-7 will be determined. The text of the policy is available at: https://www.arin.net/policy/proposals/2008_7.html Board of Trustees meeting minutes are available at: https://www.arin.net/about_us/bot/index.html Regards, Member Services Department American Registry for Internet Numbers (ARIN) From spiffnolee at yahoo.com Fri Sep 11 11:56:36 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 11 Sep 2009 08:56:36 -0700 (PDT) Subject: [arin-ppml] What to expect from an ARIN meeting Message-ID: <638947.72836.qm@web63304.mail.re1.yahoo.com> It's time to register for ARIN XXIV! Why should you attend? What should you expect? This is an excerpt from my original post, http://lists.arin.net/pipermail/arin-discuss/2009-June/001261.html As you've seen, many of the members of the Advisory Council are active on PPML. All of them read it. So every post affects their thinking. Usually, a small subcommittee of 2-3 AC members will shepherd a proposal through the process, making edits based on comments, until the AC believes it has reached a stable state. Then the AC votes on the proposal, and if passed it becomes a Draft Policy. Policy Development Process: https://www.arin.net/policy/pdp.html Handy flowchart: https://www.arin.net/policy/pdp_appendix_a.pdf The Draft Policy is the text that goes to the public policy meetings. Alternating with other informative presentations, every Draft is presented to the people present (including remote participants), beginning with a history of the proposal, including a summary of the debate so far. For instance, for proposal 2009-4 presented in San Antonio, we learned that 18 people had made 58 posts, of whom 3 were in favor, and 4 were against it (the rest apparently weren't clear about their positions). Three sample statements were presented to show some of the debate to date. https://www.arin.net/participate/meetings/reports/ARIN_XXIII/pdf/monday/2009-4_intro.pdf After that 2-minute presentation, someone will present the text of the proposal, to remind everyone what we're discussing. They might show some slides to provide context, to explain the problem. Then the floor is open for discussion, and people walk up to microphones. The Chair indicates who is next in line to speak, and people say their piece. Other people get up to respond. It's sometimes passionate, but always respectful. To describe the scene, there are rows of tables where people can plug in their laptops. There are two large screens for projecting slides. Some subset of Board and AC site facing the participants from a dais/rostrum, so you can see who they are. The presenter stands at a podium/lectern with a mike so you can hear them. There are rows between tables, with six microphones on stands, so everyone can get to a mike fairly easily. Watch two minutes of the webcast of a recent meeting to get the idea: https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppm.html There's usually a show of hands to get a sense of the room. The AC meets after the meeting, and discusses each Draft Policy. Staff provides every AC member with a summary similar to what was presented at the meeting, but including hand count. If there's a discrepancy between support on the mailing list and support in the room, there's a long debate; this is rare. The AC then votes, and if approved, it goes to Last Call on PPML to see if we missed anything. Then the Board looks at it, makes a final determination that the policy poses no risk to the organization, and adopts it (or sends it back to the AC for revision). Detailed notes, transcripts, presentation slides, and even video of the last meeting are available from here: https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppm.html I hope that gives everyone a sense of how PPML matters, and why meeting participation matters, too. Also, the meetings are fun, with great conversation at breaks and meals, and a great social event. People are approachable, but you often don't need to approach anyone--if you say something at the mike, or if you've been active on the list, people will seek you out. You're very likely to find an AC member, Board member, and staff member at your lunch table. What does it cost? Everything is detailed at https://www.arin.net/participate/meetings/ARIN-XXIV/index.html You have to arrange your own travel to Dearborn, MI. Detroit is a pretty cheap destination from many parts of the region. If you're already going to NANOG, you can just extend your stay to Friday afternoon (or the other way around--if you're coming to ARIN, consider coming early to participate in NANOG). Cab fare is $31 each way, to/from DTW/Hyatt Regency. The ARIN rate is $159 per night, but there are cheaper hotels within walking distance. Registration depends on whether you're a Designated Member Representative. Most meals are included: Tuesday night pizza and beer with NANOG, breakfast and lunch Wednesday (no dinner), breakfast lunch and heavy hors d'oevres Thursday, and breakfast Friday. There are also Fellowship (application deadline has passed) and Scholarship opportunities if cost is still a barrier. In case you missed it, here's the link one more time to register: https://www.arin.net/participate/meetings/ARIN-XXIV/index.html Disclaimer: everything I've said here is an approximation of the Truth found at ARIN's website. I hope everyone who participates on the mailing list will come to the meeting. And I hope to meet you there! Lee From info at arin.net Mon Sep 14 09:37:04 2009 From: info at arin.net (Member Services) Date: Mon, 14 Sep 2009 09:37:04 -0400 Subject: [arin-ppml] Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries Message-ID: <4AAE4700.5050508@arin.net> Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries On 20 August 2009 the ARIN Advisory Council (AC) selected 2009-3 for adoption discussion on the PPML and at the Public Policy Meeting in Dearborn. 2009-3 comes from a global policy proposal. Global policies require the agreement of all five RIRs according to their policy development processes and ratification by ICANN. And, global policies require specific actions by the IANA. After the ARIN Public Policy Meeting in April 2009 the AC returned 2009-3 to their docket for further development and evaluation. The AC revised the text. The difference between the text presented at the ARIN meeting in April and the current version is in "A. Phase I" as follows: Old ARIN "A. Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. At quarterly intervals, each RIR shall return to the IANA any legacy address space recovered, and may return to the IANA any non-legacy address space recovered, in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. New ARIN "A. Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. Draft Policy 2009-3 is below and can be found at: https://www.arin.net/policy/proposals/2009_3.html You are encouraged to discuss Draft Policy 2009-3 on the PPML prior to the October Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. Note, the ARIN version of the global proposal is different from the text at the other RIRs. The AC's version has a revised "A. Phase I" (APNIC's equivalent is prop-069, see the second paragraph of 5.1). The ARIN version also includes a definition of legacy space. The APNIC proposal can be found at: http://www.apnic.net/policy/proposals/prop-069 The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries Version/Date: 14 September 2009 Policy statement: This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. Phase I: Recovery of IPv4 Address Space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. Return of recovered address space (as described above) will continue throughout Phase II. B. Phase II: Allocation of Recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. The following definitions apply to this policy: a. Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report. b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices. c. Aggregated address blocks. Aggregated address blocks are contiguous prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two contiguous prefixes that can be combined to form an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes that cannot be combined on a natural bit boundary to form an aggregated block. d. Legacy address space. IPv4 address space allocated or assigned prior to the creation of the RIR. 2. Allocation of IPv4 Address Space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. The minimum 'IPv4 allocation unit' size will be a /24. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 3. IPv4 Address Space Allocation Criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 4. Initial Allocation of IPv4 Address Space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 5. Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. From marla.azinger at frontiercorp.com Mon Sep 14 13:32:23 2009 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 14 Sep 2009 13:32:23 -0400 Subject: [arin-ppml] IP Address Block Clean up Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> Hello- Below is a short string of a topic that started on NANOG. However, it connects directly to the ARIN realm so Im forwarding it here in case any ARIN ppml folks would like to chime in. Cheers Marla -----Original Message----- From: Azinger, Marla Sent: Monday, September 14, 2009 10:29 AM To: 'Christopher Morrow'; Chris Marlatt Cc: John Curran; nanog at nanog.org Subject: RE: Hijacked Blocks I haven't followed this entire string. Are you saying ARIN is repeatedly handing out address space to known abusers? If that's the case then yes, some form of policy should be worked on. If on the administrative level ARIN is not researching returned blocks for abuse complaints and working to clean them up, then...I suppose policy could be proposed. I'm just not sure if that's really where the brunt of assignments to abusers is happening. >From experience I learned the most effective place for abuse stopping is at the network level. Back in 2001 my network had serious problems with this. Making a sale was more important than ensuring abuse didn't occur. However, I worked to install a policy that required customer review before assigning them address space. If public records showed abuse (which was really easy to find) or public records showed a business model that would be really only something leading to abuse complaints then engineering had the veto power to not permit the potential customer onto our network. We managed to go from allot of abuse to essentially zero in 1 year. Then we worked to clean up the damaged blocks. Granted, if a network or company goes out of business they wont care if the addresses are clean when they return them to ARIN. So maybe this is where some proposal could focus. Also, if this is a case where an entity is able to qualify for direct ARIN allocations and they are habitual at turning over because their business is essentially abusing the network, then policy could focus there as well. Its easy to create a new company name, but from experience the owners name still stays the same for the most part, so a review of the company before allocation would catch that. In reality, we would all benefit if policy to stop it before it happens and policy to clean it up before reissuing existed at the registry and the network level. It would be interesting to see what legal and staff would have to say about taking those types of measures. Controlling this type of abuse and the clean up of it is one of the older arguments for not permitting just anyone direct allocations from ARIN. Abuse and clean up is better managed and cared for at the larger Network levels. Im not looking to open a debate on this last comment. ;o) Its just something that popped into my head as to one of the explanations for why specific levels of qualifications for direct allocations from ARIN existed with IPv4. My 2cents. sorry if it seemed long Cheers, Marla Azinger Frontier Communications Sr Data Engineer -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Monday, September 14, 2009 9:40 AM To: Chris Marlatt Cc: John Curran; nanog at nanog.org Subject: Re: Hijacked Blocks On Mon, Sep 14, 2009 at 11:58 AM, Chris Marlatt wrote: > Christopher Morrow wrote: >> The end of the discussion was along the lines of: "Yes, we know this >> guy is bad news, but he always comes to us with the proper paperwork >> and numbers, there's nothing in the current policy set to deny him >> address resources. Happily though he never pays his bill after the >> first 12 months so we just reclaim whatever resources are allocated >> then." ?(yes, comments about more address space ending up on BL's >> were made, and that he probably doesn't pay because after the first 3 >> months the address space is 'worthless' to him...) >> >> How should this get fixed? Is it possible to make policy to address >> this sort of problem? >> >> -chris >> > > If this is the case one could argue that ARIN should be reserving this > "worthless" address space to be used when they receive similar > requests in the future. There's no reason personX should get fresh, > clean address space when they make additional requests. That implies some process changes inside ARIN (I think) and effectively saving 'your old space' for some period of time in escrow for you. This doesn't sound unreasonable, perhaps you put forth some policy verbiage on ppml? -chris From marla.azinger at frontiercorp.com Mon Sep 14 14:50:20 2009 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 14 Sep 2009 14:50:20 -0400 Subject: [arin-ppml] Repeated Blacklisting / IP reputation, replaced by registered use In-Reply-To: <09A94A95-480E-419B-A84A-582903DA599C@virtualized.org> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> <4AAC79E6.5040802@bogus.com> <4AAE8011.1040207@mail-abuse.org> <09A94A95-480E-419B-A84A-582903DA599C@virtualized.org> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048510F3DD3@ROCH-EXCH1.corp.pvt> Another one that could be discussed at the ARIN policy bof. Also, Im forwarding this to the ARIN ppml for any further discussion. Cheers Marla -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Monday, September 14, 2009 11:44 AM To: Douglas Otis Cc: NANOG list Subject: Re: Repeated Blacklisting / IP reputation, replaced by registered use On Sep 14, 2009, at 10:40 AM, Douglas Otis wrote: > Perhaps ICANN could require registries establish a clearing-house, > where at no cost, those assigned a network would register their intent > to initiate bulk traffic, such as email, from specific addresses. ICANN can't require the RIRs do anything outside of what is specifically mentioned in global addressing policies. If you think this would be valuable and that it would make sense as a global addressing policy, then you should propose it in the RIR policy forums, get consensus amongst the five RIRs and have them forward it to ICANN as a global policy. Regards, -drc From randy at psg.com Mon Sep 14 17:03:01 2009 From: randy at psg.com (Randy Bush) Date: Tue, 15 Sep 2009 06:03:01 +0900 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> References: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> Message-ID: as i replied on nanog From: Randy Bush Subject: Re: Hijacked Blocks To: "Azinger, Marla" Cc: John Curran , North American Network Operators Group Date: Tue, 15 Sep 2009 05:47:59 +0900 > I haven't followed this entire string. Are you saying ARIN is repeatedly handing out address space to known abusers? If that's the case then yes, some form of policy should be worked on. i might walk more slowly and with a bit less self-righteousness. this is not a simple area. are we sure we want the rirs to become the net content police? how are they to judge? e.g., prudent isps act against a customer when there is a court order, not when the net gossip says they're bad actors. i.e., the decision of who is a bad actor is passed on to the society's normal judicial process. randy not that i think that bad actors should not be inhibited. i am just not sure the arin is the best way of doing so. perhaps looking at how to streamline the judicial process is an avenue that needs to be more fully explored before we become the net judges and jury. [ i also shudder thinking about a discussion here of how many commercial emails a day can dance on the head of a spam pin, etc. ] randy From kkargel at polartel.com Mon Sep 14 17:18:49 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 14 Sep 2009 16:18:49 -0500 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: References: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A152@mail> > > as i replied on nanog > > From: Randy Bush > Subject: Re: Hijacked Blocks > To: "Azinger, Marla" > Cc: John Curran , North American Network Operators > Group > Date: Tue, 15 Sep 2009 05:47:59 +0900 > > > I haven't followed this entire string. Are you saying ARIN is > repeatedly handing out address space to known abusers? If that's the case > then yes, some form of policy should be worked on. > > i might walk more slowly and with a bit less self-righteousness. this > is not a simple area. are we sure we want the rirs to become the net > content police? how are they to judge? > > e.g., prudent isps act against a customer when there is a court order, > not when the net gossip says they're bad actors. i.e., the decision > of > who is a bad actor is passed on to the society's normal judicial > process. > > randy I tend to agree with Randy on this one. While it would be wonderful to squish all the evildoers and make the internet a safe place for everyone, I do not think it is within the scope of the RiR's mission to police content or behavior. Starting that philosophy could turn into a real tar baby we would never escape from. Once one starts acting to police an issue, the onus of responsibility falls to them. ARIN has a job they do very well, we should stick with it. > > not that i think that bad actors should not be inhibited. i am just not > sure the arin is the best way of doing so. perhaps looking at how to > streamline the judicial process is an avenue that needs to be more fully > explored before we become the net judges and jury. > > [ i also shudder thinking about a discussion here of how many commercial > emails a day can dance on the head of a spam pin, etc. ] > > randy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From tedm at ipinc.net Mon Sep 14 17:29:33 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 14 Sep 2009 14:29:33 -0700 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> References: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> Message-ID: <4AAEB5BD.4070007@ipinc.net> > "In reality, we would all benefit if policy to stop it before it happens and policy to clean it up before reissuing existed at the registry " > > Cheers, > Marla Azinger > Frontier Communications > Sr Data Engineer > In my humble opinion this is really an attempt to promulgate the misguided notion that the Internet is going to be run on IPv4 for the foreseeable future. The mathematics of address allocation just don't support this. IPv4 runout (ie: end of virgin IPv4 assignments) is within 3 years: http://www.potaroo.net/tools/ipv4/index.html My liberal estimate of IPv4 reclamation is it will turn up possibly another 2 years at most of assignable IPv4 at current assignment rates. Most of this will be in itty-bitty chunks that will be useless for the large comsumers of IP addressing, so it's assignment rate will be much extended - since the small consumers of IPv4 will be the only ones feeding at that trough. During this time some IPv4 will also come into play as a result of the "transfer market" During this time more and more IPv6 will be coming into play from the large networks. Probably 5 years from end-of-IPv4 we will see the beginnings of non-dual-stacked, IPv6-only, networks. In probably a decade after runout, IPv4 will be in a surplus mode. I don't see the point in trying to create policy that ENABLES the extension of IPv4 on the Internet past it's natural lifespan. It's one thing to take IPv4 that has never seen the light of day (due to assignment fuck-ups made back in 1996 or thereabouts) and dig it out of whatever swamp it's in, blow off the dust, and use it. It's quite another to assume that IPv4 is a permanent part of the Internet and establish a framework that considers it so. In my basement I have an old 10Mhz IBM XT clone, fitted with a 8-bit ISA thinnet card, with a 10BaseT media converter on it, with the DOS version of NCSA Telnet on it. And I even have an EGA card and monitor on it so I have 16 colors!!! I appreciate all your efforts to try to keep things on the Internet so that 15 years from now, I will have the ability to pull this system out from behind the door it's propping open, and plug it into a DSL line then login to a Linux system somewhere on the Internet. But, I have a feeling by then my wife will have had me throw it out. Seriously, it's dead, Jim! Ted From marla.azinger at frontiercorp.com Mon Sep 14 17:28:01 2009 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 14 Sep 2009 17:28:01 -0400 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A152@mail> References: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A152@mail> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048510F3FBC@ROCH-EXCH1.corp.pvt> I agree. That would be one of the points from the rest of the email string thats missing from the clip here. Discussion, analysis and review is needed. Who knows after its all reviewed, analyzed and processed, the topic could be abandoned and filed away with the reasons why. But if we dont look at it, that would be slightly ignorant when some folks of the community are already asking for this to be looked at. And the points you've both made are ones that should be included in discussion. I wouldnt want to speed or push this topic through anything either. Its a complex topic. But as Chris stated "What does help is following the proper process for ARIN policies or suggestions." Cheers Marla -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Monday, September 14, 2009 2:19 PM To: arin ppml Subject: Re: [arin-ppml] IP Address Block Clean up > > as i replied on nanog > > From: Randy Bush > Subject: Re: Hijacked Blocks > To: "Azinger, Marla" > Cc: John Curran , North American Network Operators > Group > Date: Tue, 15 Sep 2009 05:47:59 +0900 > > > I haven't followed this entire string. Are you saying ARIN is > repeatedly handing out address space to known abusers? If that's the > case then yes, some form of policy should be worked on. > > i might walk more slowly and with a bit less self-righteousness. this > is not a simple area. are we sure we want the rirs to become the net > content police? how are they to judge? > > e.g., prudent isps act against a customer when there is a court order, > not when the net gossip says they're bad actors. i.e., the > decision of > who is a bad actor is passed on to the society's normal judicial > process. > > randy I tend to agree with Randy on this one. While it would be wonderful to squish all the evildoers and make the internet a safe place for everyone, I do not think it is within the scope of the RiR's mission to police content or behavior. Starting that philosophy could turn into a real tar baby we would never escape from. Once one starts acting to police an issue, the onus of responsibility falls to them. ARIN has a job they do very well, we should stick with it. > > not that i think that bad actors should not be inhibited. i am just > not sure the arin is the best way of doing so. perhaps looking at how > to streamline the judicial process is an avenue that needs to be more > fully explored before we become the net judges and jury. > > [ i also shudder thinking about a discussion here of how many > commercial emails a day can dance on the head of a spam pin, etc. ] > > randy From JOHN at egh.com Mon Sep 14 17:42:49 2009 From: JOHN at egh.com (John Santos) Date: Mon, 14 Sep 2009 17:42:49 -0400 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: Message-ID: <1090914172706.437A-100000@Ives.egh.com> On Tue, 15 Sep 2009, Randy Bush wrote: > as i replied on nanog > > From: Randy Bush > Subject: Re: Hijacked Blocks > To: "Azinger, Marla" > Cc: John Curran , North American Network Operators > Group > Date: Tue, 15 Sep 2009 05:47:59 +0900 > > > I haven't followed this entire string. Are you saying ARIN is repeatedly handing out address space to known abusers? If that's the case then yes, some form of policy should be worked on. > > i might walk more slowly and with a bit less self-righteousness. this > is not a simple area. are we sure we want the rirs to become the net > content police? how are they to judge? > > e.g., prudent isps act against a customer when there is a court order, > not when the net gossip says they're bad actors. i.e., the decision of > who is a bad actor is passed on to the society's normal judicial > process. > > randy > > not that i think that bad actors should not be inhibited. i am just not > sure the arin is the best way of doing so. perhaps looking at how to > streamline the judicial process is an avenue that needs to be more fully > explored before we become the net judges and jury. > > [ i also shudder thinking about a discussion here of how many commercial > emails a day can dance on the head of a spam pin, etc. ] > > randy In the scenario described earlier, the Bad Guy (BG) was acquiring addresses, not paying his renewal fee after a year, then applying for and getting a new address block, repeat. The poster could tell it was the same BG because although he was using a new business name each time, the contact info was the same (personal name, mailing address, etc., I would guess.) In this case, I think it would be easy for ARIN to address: You can't get a new block if you've failed to pay up on your old block, or otherwise violated their RSA. (I suppose BG could be allowed to re-instate the old block (if still available) by paying up his back fees, but this would defeat the BG's purpose, which is to get new, untainted addresses. However, it would let someone legitimate who worked for or owned a failed business to start over, especially if their original addresses were untainted and they were happy to have them back.) This wouldn't stop BG dead in his tracks (he could always hire someone to front for him), but it might slow him down. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From ppml at rs.seastrom.com Mon Sep 14 19:04:06 2009 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 14 Sep 2009 19:04:06 -0400 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: <1090914172706.437A-100000@Ives.egh.com> (John Santos's message of "Mon, 14 Sep 2009 17:42:49 -0400") References: <1090914172706.437A-100000@Ives.egh.com> Message-ID: <864or52knt.fsf@seastrom.com> John Santos writes: > This wouldn't stop BG dead in his tracks (he could always hire someone > to front for him), but it might slow him down. More likely to have the unintended consequence of complicating the lives of the folks who track such misbehavior by creating an incentive to obfuscate and hide data from the get-go. -r From bill at herrin.us Mon Sep 14 19:01:43 2009 From: bill at herrin.us (William Herrin) Date: Mon, 14 Sep 2009 19:01:43 -0400 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> References: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C79@ROCH-EXCH1.corp.pvt> Message-ID: <3c3e3fca0909141601l4c403662j39fd9342459ffc9b@mail.gmail.com> I think it might be instructive to re-frame the question: Assume: 1. John Smith runs Spamco, a direct marketing firm which sends unsolicited email. 2. Spamco more or less complies with US law. For example, it doesn't forge return addresses. 3. Spamco owns 20 servers in a colocated rack and has two ISPs. 4. John incorporates a subsidiary company called "networks extreme" in whichever state has the strongest privacy laws for the purpose of interacting with ARIN in a more or less anonymous fashion. 5. Where the information in John's application is trivially checkable or where ARIN is expected to verify the data in a manner not trivially conned, John will provide factually accurate information. 6. Anywhere else that it's advantageous, John will lie in his ARIN application. 7. John's budget for the ARIN application process is $10,000. He'll spend up to that much money on ARIN fees, incorporation and creating paper tigers which match the lies. Given these assumptions: a. How does John go about getting a /16 from ARIN? b. What paperwork does he submit? c. What process protections does ARIN use to detect and stop John's behavior? d. Is this any different if he requests a /14 or a /18? Bear in mind here that "networks extreme" is the company interacting with ARIN. It legally exists but was recently incorporated, both facts that ARIN can trivially confirm. It has no public history unless John fakes something up. No debts. No credit history. No information about the ownership or board of directors is publicly available from the state in which it was incorporated. The phone rings to a Vonage number. The postal address is "123 main st. Suite 45." 123 main street is a mailbox store in that state which anonymously forwards mail. The DNS domain John uses for email during the application is registered with the same address and phone. Hopefully, the answers are not: a. John applies to ARIN as networks extreme for the addresses. b. John supplies a fake network plan which shows extensive use of private IPs allegedly used in the R&D of network extreme's product. The product is now being rolled out. He also shows the several /24's that he conned out of his two ISPs. c. Upon a later report of abuse, ARIN asks John for more paperwork. d. no Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Mon Sep 14 21:19:19 2009 From: jcurran at arin.net (John Curran) Date: Mon, 14 Sep 2009 21:19:19 -0400 Subject: [arin-ppml] IP Address Block Clean up In-Reply-To: <1090914172706.437A-100000@Ives.egh.com> References: <1090914172706.437A-100000@Ives.egh.com> Message-ID: <002DC5E5-6491-4098-AFC0-4ECA58FD0D55@arin.net> On Sep 14, 2009, at 5:42 PM, John Santos wrote: > > In the scenario described earlier, the Bad Guy (BG) was acquiring > addresses, not paying his renewal fee after a year, then applying > for and getting a new address block, repeat. The poster could tell > it was the same BG because although he was using a new business name > each time, the contact info was the same (personal name, mailing > address, etc., I would guess.) In this case, I think it would > be easy for ARIN to address: You can't get a new block if you've > failed to pay up on your old block, or otherwise violated their RSA. I will check into this immediately. > (I suppose BG could be allowed to re-instate the old block (if still > available) by paying up his back fees, but this would defeat the BG's > purpose, which is to get new, untainted addresses. However, it would > let someone legitimate who worked for or owned a failed business to > start over, especially if their original addresses were untainted and > they were happy to have them back.) We presently take addresses revoked for non-payment and put them on hold-down for 1 year. This is important since sometimes otherwise innocent parties simply have a payment error, and we want to make sure that they get their original address space back & promptly. Note - this is also why we don't want to publish a list of blocks at the time of revocation (in addition to the one at reissuance) since if RBL's were to remove these blocks on revocation, it would only provide spammers incentive to "wash" their address space by non-payment & then cure. > This wouldn't stop BG dead in his tracks (he could always hire someone > to front for him), but it might slow him down. Will check regarding history under the same name as non-payer. Note that: 1) it may cause these folks to simply enlist "mules" for use of their name, and 2) we'll need to review for any legal issues with ARIN failing to do business with a party specifically because the debt/ credit/payment history of "related" LLC... /John President and CEO ARIN From josh at acornactivemedia.com Tue Sep 15 18:27:02 2009 From: josh at acornactivemedia.com (Joshua King) Date: Tue, 15 Sep 2009 17:27:02 -0500 Subject: [arin-ppml] 2008-3 Support Message-ID: Sorry to be late weighing in on the proposal in this whole process. I was partly responsible for the initial version of this proposal, and it grew out of a long, iterative process. Initially, my organization, Acorn Active Media Foundation, attempted to get an IPv6 address allocation from ARIN that we could experiment with and find uses for across several disparate systems that we managed across a collection of local, technology-oriented non-profits that we co-managed the computer infrastructure for; these organizations would probably be considered community networks. They include Chambana.net, a community co-location and hosting co-operative that runs a collection of servers that host mailinglists, websites, email, and other services for dozens of community organizations; the Champaign-Urbana Community Wireless Network (CUWiN), which develops open-source wireless mesh software and deploys networks both within Champaign-Urbana, Illinois where it's located and within other communities around the country; and the Urbana-Champaign Independent Media Center (UCIMC), a large community media, arts, and journalism center which runs public computer labs as well and electronic media creation training along with its other projects. We wanted to get an IPv6 allocation to see what we could do with it, for a number of reasons. We were paying $165/month for a 1Mb upstream connection and 4 "sticky" public IPv4 addresses with donations, and couldn't afford anything better (nothing was available that was less expensive, all of our equipment donated, all of our work volunteer, and no budget). We used 4 semi-static addresses to provide public services upstream from 10 servers and 80+ wireless nodes, and hoped that getting IPv6 addresses could allow us to better manage our systems for those that supported IPv6. We wanted to experiment with how global addressing space might allow us to experiment with CUWiN's mobile wireless systems, or tie together multiple networks in different locations: CUWiN manages networks in Champaign-Urbana, Illinois; Homer, Illinois; and Mesa Verda, California, and is allied with Seattle Wireless, NYC Wireless, Wireless Philadelphia, and Open Air Boston; UCIMC is the global hub of over 200 independent journalism centers worldwide. And since IPv6 is presumably the future of the Internet, we wanted to start supporting it as soon as possible (our current upstream provider didn't support IPv6). But when we tried to apply for space, ARIN didn't seem sure what to do with us. So it was recommmended that we put in a policy proposal, which would provide a niche that would encourage community networks like the ones that we represented to apply for space, by letting them know it was possible. I honestly think that this proposal would be beneficial, to the organizations like those above and others like them. Even if it doesn't eventually result in a policy that reduces fees, I think it will let community networks know that there's a place for them in the greater Internet community. A common criticism of community networks is that they are difficult to define; I think that that is unfortunately true. It's much like the phrase "community organization," commonly used in organizing and non-profit policy, that people don't really know what it means. I hesitate to refer to Wikipedia, but I feel like they give a pretty good if broad definition of community network: http://en.wikipedia.org/wiki/Community_network/. It is however a subjective definition dependent upon purpose and motivation within the group, rather than something that can be nailed down under budget, staff size, or fiscal status. Thus I agree with the need for discretion within the AC on qualifying organizations. However, here's a list of some community networks that I know of (sorry there are a lot from Illinois, and a large wireless bias; those are just regions and fields I'm involved with). Maybe they can provide an example: Acorn Active Media Foundation UCIMC CUWiN Chambana.net Tribal Digital Village, provides network services and outreach on California reservations Prairienet, a community access project and dial-up ISP sponsored by the University of Illinois Seattle Wireless, a community wireless network Personal Telco Project, a community wireless network based in Portland Portland Community Media, a community technology center (CTC) Denver Open Media, a CTC and public access station in Denver that deploys open-source publishing platforms in other public access stations Mountain Area Information Network, a CTC, public radio and television station, and ISP in Asheville, NC Ile Sans Fil, a community wireless network and volunteer open-source software developer in Montreal Austin Wireless, a community wireless network Wireless Philadelphia, first a public metro wifi network, then defunct commercial network, now getting restarted as community-oriented again Public Internet Project, digital divide outreach non-profit and community wireless network NetEquality, outreach and activism, vendor of discount wireless equipment -- Josh King -- Treasurer, Acorn Active Media Foundation Systems Engineer, Chambana.net and CUWiN Technical Coordinator, UCIMC Adjunct Technologist, Open Technology Initiative -------------- next part -------------- An HTML attachment was scrubbed... URL: From ptimmins at clearrate.com Tue Sep 15 18:30:41 2009 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Tue, 15 Sep 2009 18:30:41 -0400 Subject: [arin-ppml] 2008-3 Support In-Reply-To: References: Message-ID: Out of curiosity, how do you plan on using an IPv6 allocation if you have no transit provider who can announce it for you? Have you considered using Hurricane Electric or Freenet6 to get the space, which seems like a better fit for what you?ve got? -Paul From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joshua King Sent: Tuesday, September 15, 2009 6:27 PM To: ppml at arin.net Subject: [arin-ppml] 2008-3 Support Sorry to be late weighing in on the proposal in this whole process. I was partly responsible for the initial version of this proposal, and it grew out of a long, iterative process. Initially, my organization, Acorn Active Media Foundation, attempted to get an IPv6 address allocation from ARIN that we could experiment with and find uses for across several disparate systems that we managed across a collection of local, technology-oriented non-profits that we co-managed the computer infrastructure for; these organizations would probably be considered community networks. They include Chambana.net, a community co-location and hosting co-operative that runs a collection of servers that host mailinglists, websites, email, and other services for dozens of community organizations; the Champaign-Urbana Community Wireless Network (CUWiN), which develops open-source wireless mesh software and deploys networks both within Champaign-Urbana, Illinois where it's located and within other communities around the country; and the Urbana-Champaign Independent Media Center (UCIMC), a large community media, arts, and journalism center which runs public computer labs as well and electronic media creation training along with its other projects. We wanted to get an IPv6 allocation to see what we could do with it, for a number of reasons. We were paying $165/month for a 1Mb upstream connection and 4 "sticky" public IPv4 addresses with donations, and couldn't afford anything better (nothing was available that was less expensive, all of our equipment donated, all of our work volunteer, and no budget). We used 4 semi-static addresses to provide public services upstream from 10 servers and 80+ wireless nodes, and hoped that getting IPv6 addresses could allow us to better manage our systems for those that supported IPv6. We wanted to experiment with how global addressing space might allow us to experiment with CUWiN's mobile wireless systems, or tie together multiple networks in different locations: CUWiN manages networks in Champaign-Urbana, Illinois; Homer, Illinois; and Mesa Verda, California, and is allied with Seattle Wireless, NYC Wireless, Wireless Philadelphia, and Open Air Boston; UCIMC is the global hub of over 200 independent journalism centers worldwide. And since IPv6 is presumably the future of the Internet, we wanted to start supporting it as soon as possible (our current upstream provider didn't support IPv6). But when we tried to apply for space, ARIN didn't seem sure what to do with us. So it was recommmended that we put in a policy proposal, which would provide a niche that would encourage community networks like the ones that we represented to apply for space, by letting them know it was possible. I honestly think that this proposal would be beneficial, to the organizations like those above and others like them. Even if it doesn't eventually result in a policy that reduces fees, I think it will let community networks know that there's a place for them in the greater Internet community. A common criticism of community networks is that they are difficult to define; I think that that is unfortunately true. It's much like the phrase "community organization," commonly used in organizing and non-profit policy, that people don't really know what it means. I hesitate to refer to Wikipedia, but I feel like they give a pretty good if broad definition of community network: http://en.wikipedia.org/wiki/Community_network/. It is however a subjective definition dependent upon purpose and motivation within the group, rather than something that can be nailed down under budget, staff size, or fiscal status. Thus I agree with the need for discretion within the AC on qualifying organizations. However, here's a list of some community networks that I know of (sorry there are a lot from Illinois, and a large wireless bias; those are just regions and fields I'm involved with). Maybe they can provide an example: Acorn Active Media Foundation UCIMC CUWiN Chambana.net Tribal Digital Village, provides network services and outreach on California reservations Prairienet, a community access project and dial-up ISP sponsored by the University of Illinois Seattle Wireless, a community wireless network Personal Telco Project, a community wireless network based in Portland Portland Community Media, a community technology center (CTC) Denver Open Media, a CTC and public access station in Denver that deploys open-source publishing platforms in other public access stations Mountain Area Information Network, a CTC, public radio and television station, and ISP in Asheville, NC Ile Sans Fil, a community wireless network and volunteer open-source software developer in Montreal Austin Wireless, a community wireless network Wireless Philadelphia, first a public metro wifi network, then defunct commercial network, now getting restarted as community-oriented again Public Internet Project, digital divide outreach non-profit and community wireless network NetEquality, outreach and activism, vendor of discount wireless equipment -- Josh King -- Treasurer, Acorn Active Media Foundation Systems Engineer, Chambana.net and CUWiN Technical Coordinator, UCIMC Adjunct Technologist, Open Technology Initiative -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Wed Sep 16 13:43:37 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Sep 2009 10:43:37 -0700 Subject: [arin-ppml] 2008-3 Support In-Reply-To: References: Message-ID: <4AB123C9.5020602@ipinc.net> I live in Portland OR Portland Community Media is not a community network provider. Their mission is to do television broadcasting of various community events. Personal Telco Project is also not a community wireless network provider. They basically are a group that goes to people who want to host a free wireless node and help them setup open-wrt on a cheap router. The people have to provide the DSL or cable or whatever line from whatever ISP they get service from. Your explanation is interesting but you did not say if you attempted to get IPv6 from your $165/mth 1MB upstream provider before going to ARIN. Did you? Frankly your explanation here is in my mind a textbook case of how NOT to deploy IPv6. So, let's say ARIN gives you an IPv6 block. How are you going to connect that to the native IPv6 on the Internet? By tunneling? If that is the case, don't you see that when you setup an IPv6 tunnel to the IPv6 Internet, that your removing absolutely all incentive for your $165/mnth upstream provider to actually make an effort to support IPv6? Your also removing all incentive for your OWN organization to threaten or cajole or apply any pressure to your upstream provider to actually move to IPv6. So likely you will never do it. How much better for the rest of the Internet if you were to go to your $165/mth upstream and tell them that unless they offer you IPv6 in a year, you will go to one of their competitors! I wish you guys were here in Portland OR. I'd gladly sell you a 1MBx1MB/mnth DSL circuit and give you a nice IPv6 block for $165/mth. I'd even give you a nice IPv4 block if you can provide utilization justification!!! As an ISP admin who HAS spent the effort to get IPv6 going, it irks me when customers in my market who want IPv6 go to one of my competitors who DON'T offer it, and then tunnel, when they could come to me and get native. Those customers must think they are oh-so progressive since they are doing IPv6 tunnels to Hurricane Electric or some such. Well why the heck don't they actually support an ISP who has spent the money to do it right?!?!? Ted Joshua King wrote: > Sorry to be late weighing in on the proposal in this whole process. > > I was partly responsible for the initial version of this proposal, and > it grew out of a long, iterative process. Initially, my organization, > Acorn Active Media Foundation, attempted to get an IPv6 address > allocation from ARIN that we could experiment with and find uses for > across several disparate systems that we managed across a collection of > local, technology-oriented non-profits that we co-managed the computer > infrastructure for; these organizations would probably be considered > community networks. They include Chambana.net, a community co-location > and hosting co-operative that runs a collection of servers that host > mailinglists, websites, email, and other services for dozens of > community organizations; the Champaign-Urbana Community Wireless Network > (CUWiN), which develops open-source wireless mesh software and deploys > networks both within Champaign-Urbana, Illinois where it's located and > within other communities around the country; and the Urbana-Champaign > Independent Media Center (UCIMC), a large community media, arts, and > journalism center which runs public computer labs as well and electronic > media creation training along with its other projects. We wanted to get > an IPv6 allocation to see what we could do with it, for a number of > reasons. We were paying $165/month for a 1Mb upstream connection and 4 > "sticky" public IPv4 addresses with donations, and couldn't afford > anything better (nothing was available that was less expensive, all of > our equipment donated, all of our work volunteer, and no budget). We > used 4 semi-static addresses to provide public services upstream from 10 > servers and 80+ wireless nodes, and hoped that getting IPv6 addresses > could allow us to better manage our systems for those that supported > IPv6. We wanted to experiment with how global addressing space might > allow us to experiment with CUWiN's mobile wireless systems, or tie > together multiple networks in different locations: CUWiN manages > networks in Champaign-Urbana, Illinois; Homer, Illinois; and Mesa Verda, > California, and is allied with Seattle Wireless, NYC Wireless, Wireless > Philadelphia, and Open Air Boston; UCIMC is the global hub of over 200 > independent journalism centers worldwide. And since IPv6 is presumably > the future of the Internet, we wanted to start supporting it as soon as > possible (our current upstream provider didn't support IPv6). > > But when we tried to apply for space, ARIN didn't seem sure what to do > with us. So it was recommmended that we put in a policy proposal, which > would provide a niche that would encourage community networks like the > ones that we represented to apply for space, by letting them know it was > possible. I honestly think that this proposal would be beneficial, to > the organizations like those above and others like them. Even if it > doesn't eventually result in a policy that reduces fees, I think it will > let community networks know that there's a place for them in the greater > Internet community. > > A common criticism of community networks is that they are difficult to > define; I think that that is unfortunately true. It's much like the > phrase "community organization," commonly used in organizing and > non-profit policy, that people don't really know what it means. I > hesitate to refer to Wikipedia, but I feel like they give a pretty good > if broad definition of community network: > http://en.wikipedia.org/wiki/Community_network/. It is however a > subjective definition dependent upon purpose and motivation within the > group, rather than something that can be nailed down under budget, staff > size, or fiscal status. Thus I agree with the need for discretion within > the AC on qualifying organizations. > > However, here's a list of some community networks that I know of (sorry > there are a lot from Illinois, and a large wireless bias; those are just > regions and fields I'm involved with). Maybe they can provide an example: > Acorn Active Media Foundation > UCIMC > CUWiN > Chambana.net > Tribal Digital Village, provides network services and outreach on > California reservations > Prairienet, a community access project and dial-up ISP sponsored by the > University of Illinois > Seattle Wireless, a community wireless network > Personal Telco Project, a community wireless network based in Portland > Portland Community Media, a community technology center (CTC) > Denver Open Media, a CTC and public access station in Denver that > deploys open-source publishing platforms in other public access stations > Mountain Area Information Network, a CTC, public radio and television > station, and ISP in Asheville, NC > Ile Sans Fil, a community wireless network and volunteer open-source > software developer in Montreal > Austin Wireless, a community wireless network > Wireless Philadelphia, first a public metro wifi network, then defunct > commercial network, now getting restarted as community-oriented again > Public Internet Project, digital divide outreach non-profit and > community wireless network > NetEquality, outreach and activism, vendor of discount wireless equipment > > -- > Josh King > -- > Treasurer, Acorn Active Media Foundation > Systems Engineer, Chambana.net and CUWiN > Technical Coordinator, UCIMC > Adjunct Technologist, Open Technology Initiative > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 Thu Sep 17 09:18:09 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 17 Sep 2009 09:18:09 -0400 Subject: [arin-ppml] 2008-3 Support In-Reply-To: References: Message-ID: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> The problem that we are beating around the bush here is a fairly common one (but no less difficult) in resource allocation. Joshua is pleading a set of special circumstances that, he believes, warrant a special exception to normal ARIN v6 allocation policies. This kind of a claim can either be based on a particular status of the organization (e.g., nonprofit, community organization, etc.) or on the special and meritorious use to which the allocation would be put (e.g., the ability of local organizations to experiment, innovate, etc.) This is what we call ?merit? allocation. That is, allocations are based not on some (allegedly) objective standard of ?need? nor on the ability to pay the regular fees, but on the perceived social merit of the claim. Others call it a beauty contest - but in this case there is not really a ?contest? in that his group is not asking for one of a fixed number of slots, as happens, e.g., with broadcast licensing. So maybe we should call it a ?beauty pageant.? I strongly believe that ARIN?s v6 allocation policies should be flexible and open enough to allow organizations like Joshua?s to qualify for a v6 application ? simply because they want one, not because they ?need? one according to some v4-world definition of ?need.? I would be very concerned, however, about the prospect of complicating v6 allocation policies with a welter of special policies around specific merit claims. This would involve creating complex and always game-able classifications of organizations and uses. If we do this, I suspect, we will discover long term that for every sincere and worthy applicant like Joshua, there will be one or two entities who exploit that process in various ways to gain an unfair advantage over the other slogs who follow the normal rules. And the ability to discriminate between the gamers and the sincere-worthies will impose significant overhead on the RIRs. Here?s how I conceive of the choice. We can 1) try to forge a general policy governing merit claims, by creating an elaborate set of organizational status classifications and merit assignment criteria; or 2) establish a uniform but liberal set of rules governing access, charge appropriate fees to deter inefficient or wasteful use, and let merit claimants seek funding support from foundations, the government, their members, industry, etc. when they are unable to afford those fees. That is, the assessment of merit claims should be delegated to funders (who are more in the business of evaluating the merit of applicants) and not hardwired into (or carved out of) allocation policy. A simpler and more concrete way of saying this is that it makes a lot more sense, in the larger scheme of things, for Joshua to ask people for donations of $165/mo. to pay an ISP or to support them through the regular ARIN process than it does to structurally revise allocations policy in order to cater to merit claimants. I do think, however, that this experience ought to prompt ARIN to consider more carefully what it means by "need" for addresses in the v6 environment. --MM ________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Joshua King [josh at acornactivemedia.com] Sent: Tuesday, September 15, 2009 6:27 PM To: ppml at arin.net Subject: [arin-ppml] 2008-3 Support Sorry to be late weighing in on the proposal in this whole process. I was partly responsible for the initial version of this proposal, and it grew out of a long, iterative process. Initially, my organization, Acorn Active Media Foundation, attempted to get an IPv6 address allocation from ARIN that we could experiment with and find uses for across several disparate systems that we managed across a collection of local, technology-oriented non-profits that we co-managed the computer infrastructure for; these organizations would probably be considered community networks. They include Chambana.net, a community co-location and hosting co-operative that runs a collection of servers that host mailinglists, websites, email, and other services for dozens of community organizations; the Champaign-Urbana Community Wireless Network (CUWiN), which develops open-source wireless mesh software and deploys networks both within Champaign-Urbana, Illinois where it's located and within other communities around the country; and the Urbana-Champaign Independent Media Center (UCIMC), a large community media, arts, and journalism center which runs public computer labs as well and electronic media creation training along with its other projects. We wanted to get an IPv6 allocation to see what we could do with it, for a number of reasons. We were paying $165/month for a 1Mb upstream connection and 4 "sticky" public IPv4 addresses with donations, and couldn't afford anything better (nothing was available that was less expensive, all of our equipment donated, all of our work volunteer, and no budget). We used 4 semi-static addresses to provide public services upstream from 10 servers and 80+ wireless nodes, and hoped that getting IPv6 addresses could allow us to better manage our systems for those that supported IPv6. We wanted to experiment with how global addressing space might allow us to experiment with CUWiN's mobile wireless systems, or tie together multiple networks in different locations: CUWiN manages networks in Champaign-Urbana, Illinois; Homer, Illinois; and Mesa Verda, California, and is allied with Seattle Wireless, NYC Wireless, Wireless Philadelphia, and Open Air Boston; UCIMC is the global hub of over 200 independent journalism centers worldwide. And since IPv6 is presumably the future of the Internet, we wanted to start supporting it as soon as possible (our current upstream provider didn't support IPv6). But when we tried to apply for space, ARIN didn't seem sure what to do with us. So it was recommmended that we put in a policy proposal, which would provide a niche that would encourage community networks like the ones that we represented to apply for space, by letting them know it was possible. I honestly think that this proposal would be beneficial, to the organizations like those above and others like them. Even if it doesn't eventually result in a policy that reduces fees, I think it will let community networks know that there's a place for them in the greater Internet community. A common criticism of community networks is that they are difficult to define; I think that that is unfortunately true. It's much like the phrase "community organization," commonly used in organizing and non-profit policy, that people don't really know what it means. I hesitate to refer to Wikipedia, but I feel like they give a pretty good if broad definition of community network: http://en.wikipedia.org/wiki/Community_network/. It is however a subjective definition dependent upon purpose and motivation within the group, rather than something that can be nailed down under budget, staff size, or fiscal status. Thus I agree with the need for discretion within the AC on qualifying organizations. However, here's a list of some community networks that I know of (sorry there are a lot from Illinois, and a large wireless bias; those are just regions and fields I'm involved with). Maybe they can provide an example: Acorn Active Media Foundation UCIMC CUWiN Chambana.net Tribal Digital Village, provides network services and outreach on California reservations Prairienet, a community access project and dial-up ISP sponsored by the University of Illinois Seattle Wireless, a community wireless network Personal Telco Project, a community wireless network based in Portland Portland Community Media, a community technology center (CTC) Denver Open Media, a CTC and public access station in Denver that deploys open-source publishing platforms in other public access stations Mountain Area Information Network, a CTC, public radio and television station, and ISP in Asheville, NC Ile Sans Fil, a community wireless network and volunteer open-source software developer in Montreal Austin Wireless, a community wireless network Wireless Philadelphia, first a public metro wifi network, then defunct commercial network, now getting restarted as community-oriented again Public Internet Project, digital divide outreach non-profit and community wireless network NetEquality, outreach and activism, vendor of discount wireless equipment -- Josh King -- Treasurer, Acorn Active Media Foundation Systems Engineer, Chambana.net and CUWiN Technical Coordinator, UCIMC Adjunct Technologist, Open Technology Initiative -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Thu Sep 17 09:24:33 2009 From: marty at akamai.com (Martin Hannigan) Date: Thu, 17 Sep 2009 09:24:33 -0400 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Sep 17, 2009, at 9:18 AM, Milton L Mueller wrote: > The problem that we are beating around the bush here is a fairly > common one (but no less difficult) in resource allocation. > > Joshua is pleading a set of special circumstances that, he believes, > warrant a special exception to normal ARIN v6 allocation policies. > This kind of a claim can either be based on a particular status of > the organization (e.g., nonprofit, community organization, etc.) or > on the special and meritorious use to which the allocation would be > put (e.g., the ability of local organizations to experiment, > innovate, etc.) > > This is what we call ?merit? allocation. That is, allocations are > based not on some (allegedly) objective standard of ?need? nor on > the ability to pay the regular fees, but on the perceived social > merit of the claim. Others call it a beauty contest - but in this > case there is not really a ?contest? in that his group is not asking > for one of a fixed number of slots, as happens, e.g., with broadcast > licensing. So maybe we should call it a ?beauty pageant.? > > I strongly believe that ARIN?s v6 allocation policies should be > flexible and open enough to allow organizations like Joshua?s to > qualify for a v6 application ? simply because they want one, not > because they ?need? one according to some v4-world definition of > ?need.? I would be very concerned, however, about the prospect of > complicating v6 allocation policies with a welter of special > policies around specific merit claims. This would involve creating > complex and always game-able classifications of organizations and > uses. If we do this, I suspect, we will discover long term that for > every sincere and worthy applicant like Joshua, there will be one or > two entities who exploit that process in various ways to gain an > unfair advantage over the other slogs who follow the normal rules. > And the ability to discriminate between the gamers and the sincere- > worthies will impose significant overhead on the RIRs. > > Here?s how I conceive of the choice. We can 1) try to forge a > general policy governing merit claims, by creating an elaborate set > of organizational status classifications and merit assignment > criteria; or 2) establish a uniform but liberal set of rules > governing access, charge appropriate fees to deter inefficient or > wasteful use, and let merit claimants seek funding support from > foundations, the government, their members, industry, etc. when they > are unable to afford those fees. That is, the assessment of merit > claims should be delegated to funders (who are more in the business > of evaluating the merit of applicants) and not hardwired into (or > carved out of) allocation policy. I would fully support approach number 2. Best Regards, -M< From bill at herrin.us Thu Sep 17 10:04:17 2009 From: bill at herrin.us (William Herrin) Date: Thu, 17 Sep 2009 10:04:17 -0400 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3c3e3fca0909170704r1eb1399eof13f1560ca71d861@mail.gmail.com> On Thu, Sep 17, 2009 at 9:18 AM, Milton L Mueller wrote: > 2) establish a > uniform but liberal set of rules governing access, charge appropriate fees > to deter inefficient or wasteful use, and let merit claimants seek funding > support from foundations, the government, their members, industry, etc. when > they are unable to afford those fees. That is, the assessment of merit > claims should be delegated to funders (who are more in the business of > evaluating the merit of applicants) and not hardwired into (or carved out > of) allocation policy. I'm a big fan of option #2. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Thu Sep 17 10:31:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Sep 2009 15:31:27 +0100 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <28E139F46D45AF49A31950F88C4974580324E46E@E03MVZ2-UKDY.domain1.systemhost.net> > I strongly believe that ARIN's v6 allocation policies should > be flexible and open enough to allow organizations like > Joshua's to qualify for a v6 application - simply because > they want one, not because they "need" one according to some > v4-world definition of "need." On this I don't fully agree. I don't think that "wanting" an IPv6 allocation is sufficient. There is an IPv6 addressing model which is based on the finite size of the IPv6 address space. It allows for nearly limitless growth at several levels of the model, for instance a /64 per subnet, and a /48 per site. But at the network provider level, the supply of /32s is somewhat more limited. Here we want to restrict /32s to those organizations that provide interconnect services to many other networks/sites as a major part of their business model. Universities do this, ISPs do this, even the IT department of some geographically diverse companies do this. So there is a form of "need" here although it would be defined quite differently from the v4-world definition of need. > I would be very concerned, > however, about the prospect of complicating v6 allocation > policies with a welter of special policies around specific > merit claims. I agree with this 100%. Note that Joshua's organization can easily get IPv6 addresses by buying service from an ISP that has an IPv6 allocation. The ISP doesn't have to have native IPv6 services in order to get an allocation and assign addresses. If Joshua's organization is an early adopter, they should be able to build an ISP relationship on that basis because it is to the ISP's benefit to work together with other IPv6 early adopters. In addition, Joshua's organization could get IPv6 addresses from an IPv6 tunnel provider such as Hurricane Electric. In both cases, these are not portable addresses and would require renumbering if Joshua switches ISPs or tunnel providers. But since IPv6 is designed to make renumbering much simpler than on IPv4, this does not seem like enough hardship to deserve a special policy. > A simpler and more concrete way of saying this is that it > makes a lot more sense, in the larger scheme of things, for > Joshua to ask people for donations of $165/mo. to pay an ISP > or to support them through the regular ARIN process than it > does to structurally revise allocations policy in order to > cater to merit claimants. Yes. All of these community network organizations rely on the goodwill of their community to exist. If IPv6 addresses are needed, then they should seek the support for that within their community. If renumbering an IPv6 network is needed, similarly they should seek support for that within their community. ARIN is not the right place, given that ARIN is an international organization providing number allocations to LIRs in several countries. > I do think, however, that this experience ought to prompt > ARIN to consider more carefully what it means by "need" for > addresses in the v6 environment. Yes, I agree, and I think that all of us should consider this issue, especially in light of the IPv6 addressing framework, its current design, and the historical path by which it got to that design. --Michael Dillon From jmaimon at chl.com Thu Sep 17 10:48:45 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 17 Sep 2009 10:48:45 -0400 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <28E139F46D45AF49A31950F88C4974580324E46E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580324E46E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4AB24C4D.5000903@chl.com> michael.dillon at bt.com wrote: > But since IPv6 is > designed to make renumbering much simpler than on IPv4, this does > not seem like enough hardship to deserve a special policy. What exactly is there in practical utilization of IPv6 that makes it easier to renumber for a networking professional managing more than a single router than IPv4? From michael.dillon at bt.com Thu Sep 17 11:28:08 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Sep 2009 16:28:08 +0100 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <4AB24C4D.5000903@chl.com> Message-ID: <28E139F46D45AF49A31950F88C4974580324E5AB@E03MVZ2-UKDY.domain1.systemhost.net> > > But since IPv6 is > > designed to make renumbering much simpler than on IPv4, > this does not > > seem like enough hardship to deserve a special policy. > > What exactly is there in practical utilization of IPv6 that > makes it easier to renumber for a networking professional > managing more than a single router than IPv4? To start with there is RFC 2894, i.e. router renumbering functionality built into the IPv6 protocol suite. More recently there is RFC 4192 "Procedures for Renumbering an IPv6 Network without a Flag Day". For more info you might want to read "Preparing network configurations for IPv6 renumbering" which is available to download free at It may not be trivial or automatic but it is simpler. Things like /48 per site make it easier to switch providers since you only have to change the prefix, not the lower bits of deployed addresses. IPv6 expects hosts to have multiple addresses per interface so there is no problem in assigning the new ISP's addresses to your devices BEFORE you connect to the new ISP. And you don't have to remove the old ISP's addresses until after you have disconnected from them. Even so, it is clearly hard to renumber IPv4 networks and we don't have special policies for community networks so that they can escape from this hardship. --Michael Dillon From bill at herrin.us Thu Sep 17 13:26:17 2009 From: bill at herrin.us (William Herrin) Date: Thu, 17 Sep 2009 13:26:17 -0400 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <28E139F46D45AF49A31950F88C4974580324E5AB@E03MVZ2-UKDY.domain1.systemhost.net> References: <4AB24C4D.5000903@chl.com> <28E139F46D45AF49A31950F88C4974580324E5AB@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca0909171026h154fa700ncd0474362ca34565@mail.gmail.com> On Thu, Sep 17, 2009 at 11:28 AM, wrote: >> What exactly is there in practical utilization of IPv6 that >> makes it easier to renumber for a networking professional >> managing more than a single router than IPv4? > > To start with there is RFC 2894, i.e. router renumbering > functionality built into the IPv6 protocol suite. More > recently there is RFC 4192 "Procedures for Renumbering an > IPv6 Network without a Flag Day". Practically speaking, section 2.5 in RFC 4192 is not achievable in a complex network with currently deployed technologies. The IGP's don't support source+destination based routing, they only support destination based routing. The routers themselves can usually support source-based routing statically, but often not in the fast path (hardware-accelerated path) which in a large network has the same effect as not supporting source-based routing at all. Even if RFC 4192 offered a realistically implementable strategy for renumbering your hosts, you'd still run afoul of things like web browser DNS pinning, application-layer handling of the name to address map and the lack of timeout info in gethostbyname. Meanwhile, RFC 2894 is sketchy at best. It calls for communicating with a router via IPSec in order to change the addresses via which you're communicating with the router. Anyone who has implemented IPSec in their networks can feel free to laugh right about now. Reality check: renumbering for IPv6 is no easier and no closer to being solved than renumbering for IPv4. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Thu Sep 17 15:03:24 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Sep 2009 20:03:24 +0100 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <3c3e3fca0909171026h154fa700ncd0474362ca34565@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458032A697A@E03MVZ2-UKDY.domain1.systemhost.net> > Practically speaking, section 2.5 in RFC 4192 is not > achievable in a complex network with currently deployed > technologies. The IGP's don't support source+destination > based routing, they only support destination based routing. > The routers themselves can usually support source-based > routing statically, but often not in the fast path > (hardware-accelerated path) which in a large network has the > same effect as not supporting source-based routing at all. So then, you agree with me that RFC 4192 is a reasonable way for community networks to handle IPv6 renumbering. They rely on hand-me-down equipment and don't handle enough traffic to worry about things like the fast path. They certainly don't run large complex networks. Of course, their networks are complex, but not in the way you describe. They tend to patch together things that were never meant to be like pringle-antenna wifi links, Gatorboxes and 10-base2 point-to-point to extend beyond the reach of 10baseT cables. Not to mention old routers that don't even have a fast path. > Even if RFC 4192 offered a realistically implementable > strategy for renumbering your hosts, you'd still run afoul of > things like web browser DNS pinning, application-layer > handling of the name to address map and the lack of timeout > info in gethostbyname. Run the two ISPs in parallel for a month. > Meanwhile, RFC 2894 is sketchy at best. It calls for > communicating with a router via IPSec in order to change the > addresses via which you're communicating with the router. Nowadays we have ULA addresses for internal stuff so there is no need to ever change the IP address that you are using to access your router. > Reality check: renumbering for IPv6 is no easier and no > closer to being solved than renumbering for IPv4. You exaggerate. People with actual experience at renumbering in IPv6 have written about their experiences on the web. With foresight, it is possible to set up a network so that it can be renumbered with far less pain than an IPv4 network. --Michael Dillon From andy_lists at bananabread.net Thu Sep 17 13:59:45 2009 From: andy_lists at bananabread.net (Andrew Brown) Date: Thu, 17 Sep 2009 10:59:45 -0700 Subject: [arin-ppml] Support for Community Networks Message-ID: <4AB27911.5060103@bananabread.net> I have been working for a year on a community network for the purpose of facilitating emergency communications in a metropolitan area. The opportunity to design our network with fixed IPs to enable numerous IP service capabilities is a strong motivator for us towards adopting IPv6 if we can fall under the community network provision of the proposal 2008-3 either in its original form, or, as recently revised. We would like to see this proposal adopted as soon as possible. Andrew Brown http://svwux.org From ipgoddess.arin at gmail.com Thu Sep 17 15:34:27 2009 From: ipgoddess.arin at gmail.com (Stacy Hughes) Date: Thu, 17 Sep 2009 12:34:27 -0700 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <3c3e3fca0909170704r1eb1399eof13f1560ca71d861@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0909170704r1eb1399eof13f1560ca71d861@mail.gmail.com> Message-ID: <24c86a5f0909171234o4f221ae0q5b93c003ea4b9286@mail.gmail.com> Express support for Open Access to IPv6 and we should be all good!Stacy On Thu, Sep 17, 2009 at 7:04 AM, William Herrin wrote: > On Thu, Sep 17, 2009 at 9:18 AM, Milton L Mueller wrote: > > 2) establish a > > uniform but liberal set of rules governing access, charge appropriate > fees > > to deter inefficient or wasteful use, and let merit claimants seek > funding > > support from foundations, the government, their members, industry, etc. > when > > they are unable to afford those fees. That is, the assessment of merit > > claims should be delegated to funders (who are more in the business of > > evaluating the merit of applicants) and not hardwired into (or carved out > > of) allocation policy. > > I'm a big fan of option #2. > > 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 mueller at syr.edu Thu Sep 17 18:54:34 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 17 Sep 2009 18:54:34 -0400 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <28E139F46D45AF49A31950F88C4974580324E46E@E03MVZ2-UKDY.domain1.systemhost.net> References: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> <28E139F46D45AF49A31950F88C4974580324E46E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF5FBC8@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > I don't think that "wanting" an IPv6 > allocation is sufficient. There is an IPv6 addressing model which > is based on the finite size of the IPv6 address space. It allows > for nearly limitless growth at several levels of the model, for > instance a /64 per subnet, and a /48 per site. But at the network > provider level, the supply of /32s is somewhat more limited. Here > we want to restrict /32s to those organizations that provide > interconnect services to many other networks/sites as a major part > of their business model. Universities do this, ISPs do this, even > the IT department Sure, a /32 is a pretty big chunk of change and should not be handed out willy-nilly. But if your fee structure is right, those who get more pay more, and the small community orgs wouldn't ask for /32s and incur such fees unless they really needed them. The issue is whether they can get a /48 or /56, just because they want one. > > I do think, however, that this experience ought to prompt > > ARIN to consider more carefully what it means by "need" for > > addresses in the v6 environment. > > Yes, I agree, and I think that all of us should consider this > issue, especially in light of the IPv6 addressing framework, > its current design, and the historical path by which it got > to that design. Good to see this. Any more specific ideas? --MM From josmon at rigozsaurus.com Mon Sep 21 01:24:18 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Sun, 20 Sep 2009 23:24:18 -0600 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FFC9E6A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <20090921052418.GA7742@jeeves.rigozsaurus.com> [...] > Here's how I conceive of the choice. We can 1) try to forge a general > policy governing merit claims, by creating an elaborate set of > organizational status classifications and merit assignment criteria; or > 2) establish a uniform but liberal set of rules governing access, charge > appropriate fees to deter inefficient or wasteful use, and let merit > claimants seek funding support from foundations, the government, their > members, industry, etc. when they are unable to afford those fees. That > is, the assessment of merit claims should be delegated to funders (who > are more in the business of evaluating the merit of applicants) and not > hardwired into (or carved out of) allocation policy. I like the idea of community networks. That doesn't stop me from saying that I like Option 2) best of the two proposed... Policies are *supposed* to be general. Staff can kick things up to the board that are important enough to warrant exceptions. That's why we *have* boards -- to determine when we need to break the rules for the benefit of all. I want my "rule of law" to be based on the *intent* of the law -- not the *letter* of the law. I also want a pony. Chalk me up for option 2. From rudi.daniel at gmail.com Mon Sep 21 21:36:52 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Mon, 21 Sep 2009 21:36:52 -0400 Subject: [arin-ppml] 2008-3 Support Message-ID: <8aeeaff60909211836g7c2a09f1od3bcb19576aa1367@mail.gmail.com> I think option (1) is an unnecessary complication which could make mince meat of setting good policy and may be a good recipe for internal combustion leaving staff with headaches on the way home.So I am in support of Option (2) and make the AC the last port of call for claimants who may have exhausted all other avenues to no avail. It sounds cleaner and better stewardship of resources. Rudi Daniel Today's Topics: > > 1. Re: 2008-3 Support (John Osmon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 20 Sep 2009 23:24:18 -0600 > From: John Osmon > To: "ppml at arin.net" > Subject: Re: [arin-ppml] 2008-3 Support > Message-ID: <20090921052418.GA7742 at jeeves.rigozsaurus.com> > Content-Type: text/plain; charset=us-ascii > > [...] > > Here's how I conceive of the choice. We can 1) try to forge a general > > policy governing merit claims, by creating an elaborate set of > > organizational status classifications and merit assignment criteria; or > > 2) establish a uniform but liberal set of rules governing access, charge > > appropriate fees to deter inefficient or wasteful use, and let merit > > claimants seek funding support from foundations, the government, their > > members, industry, etc. when they are unable to afford those fees. That > > is, the assessment of merit claims should be delegated to funders (who > > are more in the business of evaluating the merit of applicants) and not > > hardwired into (or carved out of) allocation policy. > > I like the idea of community networks. That doesn't stop me from > saying that I like Option 2) best of the two proposed... > > Policies are *supposed* to be general. Staff can kick things up > to the board that are important enough to warrant exceptions. That's > why we *have* boards -- to determine when we need to break the rules > for the benefit of all. > > I want my "rule of law" to be based on the *intent* of the law -- not > the *letter* of the law. > > I also want a pony. > > Chalk me up for option 2. > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 51, Issue 13 > ***************************************** > -- Rudi Daniel Independent Consultants e Business Implementation http://www.svgpso.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Tue Sep 22 10:56:58 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 22 Sep 2009 09:56:58 -0500 Subject: [arin-ppml] 2008-3 Support In-Reply-To: <8aeeaff60909211836g7c2a09f1od3bcb19576aa1367@mail.gmail.com> References: <8aeeaff60909211836g7c2a09f1od3bcb19576aa1367@mail.gmail.com> Message-ID: <4AB8E5BA.5040404@sprunk.org> RudOlph Daniel wrote: > ... and make the AC the last port of call for claimants who may have > exhausted all other avenues to no avail. The AC and BoT members are not party to any non-disclosure agreements between ARIN and applicants, which means neither can serve as a point of appeal. This is the correct decision, since one or more (perhaps all, in some cases) AC/BoT members are likely to have a conflict of interest because they are employed by the applicant's competitors. Staff decisions can be appealed to management, i.e. people who actual ARIN employees, but no further. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From info at arin.net Tue Sep 22 14:26:02 2009 From: info at arin.net (Member Services) Date: Tue, 22 Sep 2009 14:26:02 -0400 Subject: [arin-ppml] =?utf-8?q?Advisory_Council_Meeting_Results_=E2=80=93_?= =?utf-8?q?September_2009?= Message-ID: <4AB916BA.3020204@arin.net> On 17 September 2009 the ARIN Advisory Council (AC) conducted the last call review of ?Draft Policy 2008-3: Community Networks IPv6 Assignment?. The AC found support for the draft policy and recommended it to the ARIN Board of Trustees for adoption. Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From bicknell at ufp.org Tue Sep 22 16:09:15 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 22 Sep 2009 13:09:15 -0700 Subject: [arin-ppml] Advisory Council Position Petitions? Message-ID: <20090922200915.GA14735@ussenterprise.ufp.org> Yesterday there was one petition for an AC member. Today there's an additional petition, and a note from Marty to arin-discuss. Information seems to be available at: https://www.arin.net/announcements/2009/20090922_petition.html Marty's message is at: http://lists.arin.net/pipermail/arin-discuss/2009-September/001464.html I've moved to PPML as I think the people who interact with the AC the most, and care the most about who is on the AC are on PPML, not arin-discuss. Marty's message suggests multiple people were excluded from running for some reason, and we now have two petitions that seem to back up that assertion. Are there going to be more petitions? Can someone explain what happened? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jcurran at arin.net Tue Sep 22 20:15:49 2009 From: jcurran at arin.net (John Curran) Date: Tue, 22 Sep 2009 20:15:49 -0400 Subject: [arin-ppml] Advisory Council Position Petitions? In-Reply-To: <20090922200915.GA14735@ussenterprise.ufp.org> References: <20090922200915.GA14735@ussenterprise.ufp.org> Message-ID: <79E4D32F-2940-4587-A49C-DEA9C053E025@arin.net> On Sep 22, 2009, at 4:09 PM, Leo Bicknell wrote: > Yesterday there was one petition for an AC member. Today there's > an additional petition, and a note from Marty to arin-discuss. ... > I've moved to PPML as I think the people who interact with the AC > the most, and care the most about who is on the AC are on PPML, not > arin-discuss. > > Marty's message suggests multiple people were excluded from running > for some reason, and we now have two petitions that seem to back > up that assertion. Are there going to be more petitions? Can someone > explain what happened? Leo - The NomCom is chartered with delivering a sufficient ballot for each election. The ARIN Bylaws specify that such a ballot shall consist of the number of seats being filled + 1 as a minimum. There is no maximum specified, nor any requirement to deliver all candidates to the ballot. The NomCom selects those nominees that is feels are most qualified and builds a ballot for each election. There is no assurance of selection, even if that has been the practice in the past. This is exactly how the NomCom process was set up to function, as it was considered far better than the Board selecting new BoT and AC members (as in ARIN's original Bylaws) but still allowed for in-depth consideration of each candidate in closed session. This process, by the way, is materially the same one used by other Internet organizations in their selection process. The availability of a petition process is felt to be reasonable safety value to insure that candidates who feel that they are well-qualified despite the NomCom recommendation may take the matter to the community. I welcome any and all suggestions for improvement of the process, but Marty was correct that this is not a matter of Internet number resource policy, so please send suggestions to me directly or to "arin- discuss" as desired. /John John Curran President and CEO ARIN From info at arin.net Wed Sep 23 09:52:52 2009 From: info at arin.net (Member Services) Date: Wed, 23 Sep 2009 09:52:52 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2009=2E4_=96_Editorial_updates?= Message-ID: <4ABA2834.7020808@arin.net> A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2009.4 contains the following editorial updates: * The diagram of the address hierarchy in Section 6.2 was updated. * The editor?s note, status and abstract were removed from Section 6.0. These updates were reviewed by the ARIN Advisory Council as noted in the minutes of their meeting which took place 16 July 2009. NRPM version 2009.4 is effective 23 September 2009 and supersedes the previous version. The NRPM can be found at: https://www.arin.net/policy/nrpm.html The NRPM Change Log: https://www.arin.net/policy/nrpm_changelog.html AC minutes are available at: https://www.arin.net/about_us/ac/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) From owen at delong.com Tue Sep 29 18:30:34 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Sep 2009 15:30:34 -0700 Subject: [arin-ppml] Dearborn: Calling all CAcert and/or Thawte Notaries Message-ID: It occurs to me that in addition to the PGP key signings that tend to happen at NANOG meetings it might be worth having a group notary event for CAcert and/ or Thawte notarizations. I'm currently a 10 point notary with Thawte and hope to be a CAcert notary before the Dearborn meeting. I suspect there are other notaries on the list attending the meeting. If you're a notary and will be attending the meeting, please contact me off list if you'd be interested/willing to participate in a notary get together. If there's enough support to make it feasible, I'll try to put together a way we can do it. (Perhaps we can take a corner of the PGP key signing or such). If you're looking to get notarized, here's what you will need to bring: Thawte: 1. Your original IDs. One has to be the ID you provided the Thawte web site. Two IDs are ideal. At least one of the IDs must be government issue and must have your picture. (It helps if you look like the picture, too). 2. Photocopies of your IDs (one for each notary that will provide an on-line assurance of your ID). CAcert: 1. Print out one copy of the pre-filled out assurance form from the CAcert web site for each notary. 2. Bring your original ID(s). One government issued ID is required. Additional ID is also preferred. If there is enough interest from notaries, I will post back to the list when I get arrangements made. Owen