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 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: 2008-7: Identify Invalid WHOIS =?windows-1252?Q?POC=92s_-_Ad?= =?windows-1252?Q?opted?= 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 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: 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 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: Advisory Council Meeting Results =?UTF-8?B?4oCTIFNlcHRlbWJlciAyMA==?= =?UTF-8?B?MDk=?= 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 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: NRPM 2009.4 =?windows-1252?Q?=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)