From info at arin.net Tue Sep 1 13:01:16 2015 From: info at arin.net (ARIN) Date: Tue, 01 Sep 2015 13:01:16 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-6: Transfers and Multi-national Networks - revised In-Reply-To: <5589BC46.20403@arin.net> References: <5589BC46.20403@arin.net> Message-ID: <55E5D9DC.5020403@arin.net> ARIN-2015-6 has been revised. You are encouraged to discuss the merits and your concerns of Draft Policy 2015-6 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community ARIN-2015-6 is below and can be found at: https://www.arin.net/policy/proposals/2015_6.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-6 Transfers and Multi-national Networks Date: 25 August 2015 Problem statement: Some organizations within the ARIN region are currently unable to receive IPv4 space via transfer based on current ARIN policy, which prohibits address space used outside of the ARIN region from being considered efficiently utilized. This proposal would allow organizations with a strong and long-standing presence in the ARIN region to be able to receive number resources via transfer for their global operations. Policy statement: When evaluating transfer requests, ARIN will not consider the geographic location where an organization is utilizing, or will utilize, its ARIN-registered addresses if that organization, its parent, or a subsidiary: 1. has been an ARIN customer for at least 36 months; AND 2. is currently in good standing with ARIN; AND 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND 4. can demonstrate it has a meaningful business that operates in the ARIN region. Comments: Timetable for implementation: Immediate ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-6 TRANSFERS AND MULTI-NATIONAL NETWORKS https://www.arin.net/policy/proposals/2015_6.html Date of Assessment: 18 August 2015 ___ 1. Summary (Staff Understanding) This proposal states that when evaluating transfer requests, ARIN will not consider the geographic location where an organization is utilizing its ARIN-registered addresses if that organization, its parent, or a subsidiary are able to satisfy each of the four stated criteria. ___ 2. Comments A. ARIN Staff Comments ?During the course of a transfer request, staff will consider and review the utilization of any block issued by ARIN to that organization, regardless of whether that address space is being used outside of the ARIN region. ?This policy enables organizations to qualify as a recipient for 8.3 or 8.4 transfers in the ARIN region when they might not have otherwise been able to do so. ARIN staff would now be able to consider their global utilization, instead of only their in-ARIN region use. ?One of the elements ARIN staff uses to determine 24-month need for an organization is their historical utilization rate. This proposal allows organizations to justify a larger 24-month needs based qualification, because staff will consider their utilization globally instead of just what was used inside the ARIN region. ?The policy proposal text appears to not align with the intent of the policy as described in the problem statement. This proposal changes how ARIN considers prior utilization of IPv4 address space, but does not specify that newly received resources can be used outside of the region. Existing policy and practice would dictate ARIN continues to issue space for use in the ARIN region. We note that 2015-5, if adopted, could change this. ?This would be placed in a new section of the NRPM called "8.5 Additional Transfer Policies". ?This policy could be implemented as written. B. ARIN General Counsel ? Legal Assessment No material legal issues. If the policy is enacted it will require ARIN staff to work with counsel with some attendant increase in costs in the first year to manage implementation. ___ 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. However, it could have future staffing implications based on the amount of additional work the policy could present. 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: * Updated guidelines and internal procedures * Staff training ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2015-6 Date: 23 June 2015 Problem statement: Some organizations within the ARIN region are currently unable to receive IPv4 space via transfer based on current ARIN policy, which prohibits address space used outside of the ARIN region from being considered efficiently utilized. This proposal would allow organizations with a strong and long-standing presence in the ARIN region to be able to receive number resources via transfer for their global operations. Policy statement: When evaluating transfer requests, ARIN will not consider the geographic location where an organization is utilizing its ARIN-registered addresses if that organization, its parent, or a subsidiary: 1. has been an ARIN customer for at least 36 months; AND 2. is currently in good standing with ARIN; AND 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND 4. can demonstrate it has a meaningful business that operates in the ARIN region. From info at arin.net Tue Sep 1 13:20:54 2015 From: info at arin.net (ARIN) Date: Tue, 01 Sep 2015 13:20:54 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments Message-ID: <55E5DE76.3080207@arin.net> ARIN-2015-1 has been revised to show only the proposed addition to the policy. ARIN-2015-1 is below and can be found at: https://www.arin.net/policy/proposals/2015_1.html You are encouraged to discuss Draft Policy 2015-1 on the PPML prior to the ARIN Public Policy Consultation at ARIN 36 in Montreal in October 2015. 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. ARIN-2015-1 is below and can be found at: https://www.arin.net/policy/proposals/2015_1.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2015-1 Modification to Criteria for IPv6 Initial End-User Assignments Date: 27 August 2015 AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2015-1 enables fair and impartial number resource administration by providing a concrete threshold (13 active sites) under which end-user organizations who have a large number of potentially geographically dispersed sites, or sites with low subnet and/or user counts, can be reasonably assured of receiving IPv6 address space from ARIN. This proposal is technically sound, in that it retains reasonable thresholds on obtaining IPv6 assignments from ARIN in order to support the aggregation of Internet number resources in a hierarchical manner to the extent feasible. It has been well supported by the community on PPML and at the ARIN PPC at NANOG in San Francisco, where nearly everyone agreed that this was a step in the right direction. To the extent that some in the community desire even more relaxed IPv6 assignment policy, the AC encourages those community members to discuss on PPML and/or submit as additional policy proposals any further changes they would like to see. Problem Statement: Current policy for assignment to end users excludes a class of users whose costs to renumber would far exceed what current policy is designed to mitigate. Current measures designed to minimize the economic cost of renumbering per NRPM 6.5.8.1 (Initial Assignment Criteria) are: c. By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; These two measures fail to take into account end users who have a large number of potentially geographically dispersed sites, or sites with low subnet and/or user counts. The economic costs for this class of end user would likely far exceed the costs that 6.5.8.1 c. and d. are designed to mitigate. While an end user could possibly apply (and receive an assignment) under 6.5.8.1 e. ("By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable"), it fails to provide a concrete threshold under which this class of end-user can be reasonably assured of receiving address space. Without having the reasonable assurance of IPv6 address number resource continuity that a direct assignment allows, many smaller enterprises are unlikely to adopt IPv6 (currently perceived as an already tenuous proposition for most users given current cost/benefit); or are likely to adopt technical measures (such as using ULA addressing + NAT66) that are widely held to be damaging to the IPv6 Internet. Policy Statement: Renumber NRPM 6.5.8.1 Initial Assignment Criteria subsection e. to f. and and insert a new subsection e. with the following text: By having a contiguous network that has a minimum of 13 active sites within 12 months, or; Comments: a. Timetable for implementation: Immediate b. General Comments: - The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which specifies 13 sites as the minimum number of sites required to receive a /40 initial assignment, to attempt to provide a balance between the costs of carrying the prefix vs. the costs to the end-user in renumbering. - Further constraints were added in that the sites must be in a contiguous network, to further attempt to reduce the costs of carrying the prefix - By introducing this new threshold, we attempt to restore equivalency of number resources for those end-users whose economic costs to renumber are equal to that of other end-users who would qualify for a direct assignment under 6.5.8.1 c. and d. c. Example: Example of an end-user who would not qualify under 6.5.8.2 c. or d.: - 50 locations (IPVPN) spread across the country/continent - 10 staff per location (average; 500 total) - 20 devices per location (average; 1000 total) - 2 subnets (voice & data) per location (average, 100 total) - Not multihomed - Currently using RFC1918 IPv4 space + NAT This end-user only benefits minimally from IPv6 multihoming as they are using an IPVPN, and multihoming provides benefit only for Internet transit, not within their IPVPN. As such requiring the end-user to multihome under NRPM 6.5.8.2 b. is wasteful. This end user currently uses RFC1918 IPv4 address space + a relatively small amount of IPv4 GUA + NAT (currently accepted industry practice for IPv4). Changing providers involves only renumbering the small amount of IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment under NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 assignment is incredibly wasteful of a valuable and limited number resource. It also forces the customer occupy more routing table space, as now an IPv4 PI prefix must be routed in addition to an IPv6 PI prefix, instead of using IPv4 PA + IPv6 PI (where only space for an IPv6 PI prefix is required). ##### ARIN STAFF ASSESSMENT Draft Policy ARIN-2015-1 Modification to Criteria for IPv6 Initial End-User Assignments https://www.arin.net/policy/proposals/2015_1.html Date of Assessment: June 11, 2015 ___ 1. Summary (Staff Understanding) This proposal would add a criteria item to 6.5.8.1 (Initial Assignment Criteria). Because each of the existing criteria items in that section can independently qualify an organization for IPv6 address space from ARIN, this new criteria item adds an additional qualification criteria. It makes it easier for some organizations to qualify, and does not make it more difficult for anyone. In particular, it creates a new criteria point that allows any end-user organization large enough to have 13 sites to immediately qualify for IPv6 address space from ARIN. ___ 2. Comments A. ARIN Staff Comments This proposal can be implemented as written. Minimal staff training and preparation would be needed to implement this if it were to become policy. We see no negative impacts. B. ARIN General Counsel ? Legal Assessment Counsel sees no material legal issues in this policy. ___ 3. Resource Impact This policy would require minimal staff training and preparation. We see no negative impacts. ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2015-1 Modification to Criteria for IPv6 Initial End-User Assignments Date: 24 March 2015 Problem Statement: Current policy for assignment to end users excludes a class of users whose costs to renumber would far exceed what current policy is designed to mitigate. Current measures designed to minimize the economic cost of renumbering per NRPM 6.5.8.1 (Initial Assignment Criteria) are: c. By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; These two measures fail to take into account end users who have a large number of potentially geographically dispersed sites, or sites with low subnet and/or user counts. The economic costs for this class of end user would likely far exceed the costs that 6.5.8.1 c. and d. are designed to mitigate. While an end user could possibly apply (and receive an assignment) under 6.5.8.1 e. ("By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable"), it fails to provide a concrete threshold under which this class of end-user can be reasonably assured of receiving address space. Without having the reasonable assurance of IPv6 address number resource continuity that a direct assignment allows, many smaller enterprises are unlikely to adopt IPv6 (currently perceived as an already tenuous proposition for most users given current cost/benefit); or are likely to adopt technical measures (such as using ULA addressing + NAT66) that are widely held to be damaging to the IPv6 Internet. Policy Statement: Replace the contents of NRPM 6.5.8.1 with: 6.5.8.1. Initial Assignment Criteria Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By having a contiguous network that has a minimum of 13 active sites within 12 months, or; f. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to: > An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc. > Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 2000 or more individuals either internal or external to the organization. > An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193). > An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS. Comments: a. Timetable for implementation: Immediate b. General Comments: - Changes to NRPM 6.5.8.1 are to renumber subsection e. to f. and and insert a new subsection e. with the following text: "By having a contiguous network that has a minimum of 13 active sites within 12 months, or; - The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which specifies 13 sites as the minimum number of sites required to receive a /40 initial assignment, to attempt to provide a balance between the costs of carrying the prefix vs. the costs to the end-user in renumbering. - Further constraints were added in that the sites must be in a contiguous network, to further attempt to reduce the costs of carrying the prefix - By introducing this new threshold, we attempt to restore equivalency of number resources for those end-users whose economic costs to renumber are equal to that of other end-users who would qualify for a direct assignment under 6.5.8.1 c. and d. c. Example: Example of an end-user who would not qualify under 6.5.8.2 c. or d.: - 50 locations (IPVPN) spread across the country/continent - 10 staff per location (average; 500 total) - 20 devices per location (average; 1000 total) - 2 subnets (voice & data) per location (average, 100 total) - Not multihomed - Currently using RFC1918 IPv4 space + NAT This end-user only benefits minimally from IPv6 multihoming as they are using an IPVPN, and multihoming provides benefit only for Internet transit, not within their IPVPN. As such requiring the end-user to multihome under NRPM 6.5.8.2 b. is wasteful. This end user currently uses RFC1918 IPv4 address space + a relatively small amount of IPv4 GUA + NAT (currently accepted industry practice for IPv4). Changing providers involves only renumbering the small amount of IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment under NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 assignment is incredibly wasteful of a valuable and limited number resource. It also forces the customer occupy more routing table space, as now an IPv4 PI prefix must be routed in addition to an IPv6 PI prefix, instead of using IPv4 PA + IPv6 PI (where only space for an IPv6 PI prefix is required). From ggiesen+arin-ppml at giesen.me Tue Sep 1 16:18:42 2015 From: ggiesen+arin-ppml at giesen.me (Gary T. Giesen) Date: Tue, 1 Sep 2015 16:18:42 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments In-Reply-To: <55E5DE76.3080207@arin.net> References: <55E5DE76.3080207@arin.net> Message-ID: <060301d0e4f3$660abcf0$322036d0$@giesen.me> I support the policy as written. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: September 1, 2015 1:21 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to > Criteria for IPv6 Initial End-User Assignments > > ARIN-2015-1 has been revised to show only the proposed addition to the > policy. > > ARIN-2015-1 is below and can be found at: > https://www.arin.net/policy/proposals/2015_1.html > > You are encouraged to discuss Draft Policy 2015-1 on the PPML prior to the > ARIN Public Policy Consultation at ARIN 36 in Montreal in October 2015. 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. > > ARIN-2015-1 is below and can be found at: > https://www.arin.net/policy/proposals/2015_1.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2015-1 > Modification to Criteria for IPv6 Initial End-User Assignments > > Date: 27 August 2015 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > ARIN-2015-1 enables fair and impartial number resource administration by > providing a concrete threshold (13 active sites) under which end-user > organizations who have a large number of potentially geographically > dispersed sites, or sites with low subnet and/or user counts, can be > reasonably assured of receiving IPv6 address space from ARIN. This proposal > is technically sound, in that it retains reasonable thresholds on obtaining IPv6 > assignments from ARIN in order to support the aggregation of Internet > number resources in a hierarchical manner to the extent feasible. It has been > well supported by the community on PPML and at the ARIN PPC at NANOG in > San Francisco, where nearly everyone agreed that this was a step in the right > direction. To the extent that some in the community desire even more > relaxed IPv6 assignment policy, the AC encourages those community > members to discuss on PPML and/or submit as additional policy proposals > any further changes they would like to see. > > Problem Statement: > > Current policy for assignment to end users excludes a class of users whose > costs to renumber would far exceed what current policy is designed to > mitigate. > > Current measures designed to minimize the economic cost of renumbering > per NRPM 6.5.8.1 (Initial Assignment Criteria) are: > > c. By having a network that makes active use of a minimum of 2000 IPv6 > addresses within 12 months, or; d. By having a network that makes active use > of a minimum of 200 /64 subnets within 12 months, or; > > These two measures fail to take into account end users who have a large > number of potentially geographically dispersed sites, or sites with low subnet > and/or user counts. The economic costs for this class of end user would likely > far exceed the costs that 6.5.8.1 c. and d. are designed to mitigate. > > While an end user could possibly apply (and receive an assignment) under > 6.5.8.1 e. ("By providing a reasonable technical justification indicating why > IPv6 addresses from an ISP or other LIR are unsuitable"), it fails to provide a > concrete threshold under which this class of end-user can be reasonably > assured of receiving address space. > > Without having the reasonable assurance of IPv6 address number resource > continuity that a direct assignment allows, many smaller enterprises are > unlikely to adopt IPv6 (currently perceived as an already tenuous proposition > for most users given current cost/benefit); or are likely to adopt technical > measures (such as using ULA addressing + NAT66) that are widely held to be > damaging to the IPv6 Internet. > > Policy Statement: > > Renumber NRPM 6.5.8.1 Initial Assignment Criteria subsection e. to f. > and and insert a new subsection e. with the following text: > > By having a contiguous network that has a minimum of 13 active sites within > 12 months, or; > > Comments: > a. Timetable for implementation: Immediate b. General Comments: > > - The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which > specifies 13 sites as the minimum number of sites required to receive a > /40 initial assignment, to attempt to provide a balance between the costs of > carrying the prefix vs. the costs to the end-user in renumbering. > > - Further constraints were added in that the sites must be in a contiguous > network, to further attempt to reduce the costs of carrying the prefix > > - By introducing this new threshold, we attempt to restore equivalency of > number resources for those end-users whose economic costs to renumber > are equal to that of other end-users who would qualify for a direct > assignment under 6.5.8.1 c. and d. > > c. Example: > > Example of an end-user who would not qualify under 6.5.8.2 c. or d.: > > - 50 locations (IPVPN) spread across the country/continent > - 10 staff per location (average; 500 total) > - 20 devices per location (average; 1000 total) > - 2 subnets (voice & data) per location (average, 100 total) > - Not multihomed > - Currently using RFC1918 IPv4 space + NAT > > This end-user only benefits minimally from IPv6 multihoming as they are > using an IPVPN, and multihoming provides benefit only for Internet transit, > not within their IPVPN. As such requiring the end-user to multihome under > NRPM 6.5.8.2 b. is wasteful. > > This end user currently uses RFC1918 IPv4 address space + a relatively small > amount of IPv4 GUA + NAT (currently accepted industry practice for IPv4). > Changing providers involves only renumbering the small amount of > IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment under > NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 assignment is > incredibly wasteful of a valuable and limited number resource. It also forces > the customer occupy more routing table space, as now an IPv4 PI prefix must > be routed in addition to an IPv6 PI prefix, instead of using IPv4 PA + IPv6 PI > (where only space for an IPv6 PI prefix is required). > > ##### > > ARIN STAFF ASSESSMENT > > Draft Policy ARIN-2015-1 > Modification to Criteria for IPv6 Initial End-User Assignments > https://www.arin.net/policy/proposals/2015_1.html > > Date of Assessment: June 11, 2015 > > ___ > 1. Summary (Staff Understanding) > This proposal would add a criteria item to 6.5.8.1 (Initial Assignment Criteria). > Because each of the existing criteria items in that section can independently > qualify an organization for IPv6 address space from ARIN, this new criteria > item adds an additional qualification criteria. > It makes it easier for some organizations to qualify, and does not make it > more difficult for anyone. In particular, it creates a new criteria point that > allows any end-user organization large enough to have 13 sites to > immediately qualify for IPv6 address space from ARIN. > > ___ > 2. Comments > A. ARIN Staff Comments > This proposal can be implemented as written. Minimal staff training and > preparation would be needed to implement this if it were to become policy. > We see no negative impacts. > > B. ARIN General Counsel ? Legal Assessment Counsel sees no material legal > issues in this policy. > > ___ > 3. Resource Impact > This policy would require minimal staff training and preparation. We see no > negative impacts. > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2015-1 > Modification to Criteria for IPv6 Initial End-User Assignments > > Date: 24 March 2015 > > Problem Statement: > Current policy for assignment to end users excludes a class of users whose > costs to renumber would far exceed what current policy is designed to > mitigate. > > Current measures designed to minimize the economic cost of renumbering > per NRPM 6.5.8.1 (Initial Assignment Criteria) are: > > c. By having a network that makes active use of a minimum of 2000 IPv6 > addresses within 12 months, or; d. By having a network that makes active use > of a minimum of 200 /64 subnets within 12 months, or; > > These two measures fail to take into account end users who have a large > number of potentially geographically dispersed sites, or sites with low subnet > and/or user counts. The economic costs for this class of end user would likely > far exceed the costs that 6.5.8.1 c. and d. are designed to mitigate. > > While an end user could possibly apply (and receive an assignment) under > 6.5.8.1 e. ("By providing a reasonable technical justification indicating why > IPv6 addresses from an ISP or other LIR are unsuitable"), it fails to provide a > concrete threshold under which this class of end-user can be reasonably > assured of receiving address space. > > Without having the reasonable assurance of IPv6 address number resource > continuity that a direct assignment allows, many smaller enterprises are > unlikely to adopt IPv6 (currently perceived as an already tenuous proposition > for most users given current cost/benefit); or are likely to adopt technical > measures (such as using ULA addressing + NAT66) that are widely held to be > damaging to the IPv6 Internet. > > Policy Statement: > > Replace the contents of NRPM 6.5.8.1 with: > > 6.5.8.1. Initial Assignment Criteria > > Organizations may justify an initial assignment for addressing devices directly > attached to their own network infrastructure, with an intent for the > addresses to begin operational use within 12 months, by meeting one of the > following criteria: > > a. Having a previously justified IPv4 end-user assignment from ARIN or one > of its predecessor registries, or; b. Currently being IPv6 Multihomed or > immediately becoming IPv6 Multihomed and using an assigned valid global > AS number, or; c. By having a network that makes active use of a minimum of > 2000 IPv6 addresses within 12 months, or; d. By having a network that makes > active use of a minimum of 200 /64 subnets within 12 months, or; e. By > having a contiguous network that has a minimum of 13 active sites within 12 > months, or; f. By providing a reasonable technical justification indicating why > IPv6 addresses from an ISP or other LIR are unsuitable. > > Examples of justifications for why addresses from an ISP or other LIR may be > unsuitable include, but are not limited to: > > > An organization that operates infrastructure critical to life safety > or the functioning of society can justify the need for an assignment based on > the fact that renumbering would have a broader than expected impact than > simply the number of hosts directly involved. These would > include: hospitals, fire fighting, police, emergency response, power or energy > distribution, water or waste treatment, traffic management and control, etc. > > Regardless of the number of hosts directly involved, an organization > can justify the need for an assignment if renumbering would affect 2000 or > more individuals either internal or external to the organization. > > An organization with a network not connected to the Internet can > justify the need for an assignment by documenting a need for guaranteed > uniqueness, beyond the statistical uniqueness provided by ULA (see RFC > 4193). > > An organization with a network not connected to the Internet, such as > a VPN overlay network, can justify the need for an assignment if they require > authoritative delegation of reverse DNS. > > Comments: > a. Timetable for implementation: Immediate b. General Comments: > > - Changes to NRPM 6.5.8.1 are to renumber subsection e. to f. and and insert > a new subsection e. with the following text: > > "By having a contiguous network that has a minimum of 13 active sites within > 12 months, or; > > - The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which > specifies 13 sites as the minimum number of sites required to receive a > /40 initial assignment, to attempt to provide a balance between the costs of > carrying the prefix vs. the costs to the end-user in renumbering. > > - Further constraints were added in that the sites must be in a contiguous > network, to further attempt to reduce the costs of carrying the prefix > > - By introducing this new threshold, we attempt to restore equivalency of > number resources for those end-users whose economic costs to renumber > are equal to that of other end-users who would qualify for a direct > assignment under 6.5.8.1 c. and d. > > c. Example: > > Example of an end-user who would not qualify under 6.5.8.2 c. or d.: > > - 50 locations (IPVPN) spread across the country/continent > - 10 staff per location (average; 500 total) > - 20 devices per location (average; 1000 total) > - 2 subnets (voice & data) per location (average, 100 total) > - Not multihomed > - Currently using RFC1918 IPv4 space + NAT > > This end-user only benefits minimally from IPv6 multihoming as they are > using an IPVPN, and multihoming provides benefit only for Internet transit, > not within their IPVPN. As such requiring the end-user to multihome under > NRPM 6.5.8.2 b. is wasteful. > > This end user currently uses RFC1918 IPv4 address space + a relatively small > amount of IPv4 GUA + NAT (currently accepted industry practice for IPv4). > Changing providers involves only renumbering the small amount of > IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment under > NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 assignment is > incredibly wasteful of a valuable and limited number resource. It also forces > the customer occupy more routing table space, as now an IPv4 PI prefix must > be routed in addition to an IPv6 PI prefix, instead of using IPv4 PA + IPv6 PI > (where only space for an IPv6 PI prefix is required). > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing 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 narten at us.ibm.com Fri Sep 4 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 04 Sep 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201509040453.t844r3qw013162@rotala.raleigh.ibm.com> Total of 12 messages in the last 7 days. script run at: Fri Sep 4 00:53:03 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 2 | 23.31% | 37204 | ggiesen+arin-ppml at giesen.me 16.67% | 2 | 17.58% | 28054 | info at arin.net 16.67% | 2 | 17.27% | 27569 | ggiesen at giesen.me 16.67% | 2 | 8.82% | 14074 | jcurran at arin.net 8.33% | 1 | 13.12% | 20950 | bill at tknow.com 8.33% | 1 | 11.64% | 18582 | andrew.dul at quark.net 8.33% | 1 | 4.59% | 7326 | narten at us.ibm.com 8.33% | 1 | 3.67% | 5865 | alfeh at me.com --------+------+--------+----------+------------------------ 100.00% | 12 |100.00% | 159624 | Total From lsawyer at gci.com Tue Sep 8 15:10:04 2015 From: lsawyer at gci.com (Leif Sawyer) Date: Tue, 8 Sep 2015 19:10:04 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy Message-ID: ARIN Legal and Staff have conducted a review of Draft Policy 2015-3. ARIN Advisory Council are seeking any additional feedback on this draft policy, prior to public discussion at ARIN 36 in Montreal next month. The text of the staff review is below: ___ Date of Assessment: 18 August 2015 ___ 1. Summary (Staff Understanding) This proposal would remove the 25% utilization (within 30 days of issuance) criteria bullet point from NRPM 4.3.3. ___ 2. Comments A. ARIN Staff Comments This policy would more closely align with the way staff applies the existing policy in relation to 8.3 transfers. Because there is no longer an IPv4 free pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the adoption of this policy should have no major impact on operations and could be implemented as written. Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within 30 days of issuance) requirement. Staff suggests removing the first two sentences of 4.2.3.6 to remove the references to RFC 2050 and the 25% requirement. Additionally, staff suggests removing the reference to the obsolete RFC 2050 in section 4.3.3. B. ARIN General Counsel ? Legal Assessment No material legal risk in this policy. ___ 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur immediately after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training ___ From info at arin.net Wed Sep 9 09:38:37 2015 From: info at arin.net (ARIN) Date: Wed, 09 Sep 2015 09:38:37 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised Message-ID: <55F0365D.6010409@arin.net> ARIN-2015-5 has been revised. You are encouraged to discuss the merits and your concerns of Draft Policy 2015-5 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community ARIN-2015-5 is below and can be found at: https://www.arin.net/policy/proposals/2015_5.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-5 Out of region use Date: 9 September 2015 Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows: * IPv4: At least a /22 used in region * IPv6: At least a /44 used in region * ASN: At least one ASN present on one or more peering sessions and/or routers within the region. A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner, whether for or not for profit. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. * Demonstrating that the entity provides services to or solicits sales from residents of the ARIN region. * Demonstrating that the entity holds annual meetings in the ARIN region. * Demonstrating that the entity raises investment capital from investors in the ARIN region. * Demonstrating that the entity has a registered office in the ARIN region, although this factor on its own shall not be sufficient. * Any other method that the entity considers appropriate. The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. Comments: a) Timetable for implementation: Various iterations of this policy have been presented and debated by ARIN for well over a year now. Given the amount of time that has already been spent on developing a policy, ideally, this policy would be implemented as soon as possible. b) Explanation of draft policy: The draft policy addresses both the problem statement as well as the concerns raised at ARIN 35 by participants as well as ARIN counsel. Firstly, the draft policy addresses the concerns of ARIN counsel as well as some of the participants at ARIN 35 by ensuring that anyone requesting numbered resources from ARIN has a real and substantial connection with the ARIN region. This should go a long way to addressing concerns about fraud, legal liability, and interference with the jurisdiction of other RIRs. In addition, by placing the burden of proof for demonstrating a real and substantial connection with the ARIN region on the applicant, the amount of work required of ARIN staff to apply the policy will be reduced. The factors noted above are suggestions that an entity may use to demonstrate to ARIN that it is carrying on business in the ARIN region in a meaningful manner. These factors are all indicative, some more than others, that an entity has a real and substantial connection to the ARIN region through the carrying on of business in the ARIN region in a meaningful manner. Not all of the factors will apply in a given case and proving a single factor may not be enough to satisfy ARIN that an entity is carrying on business in the region in a meaningful manner. The list of factors is meant to be quite broad, including an open-ended factor, in order to capture the diversity of businesses that operate in the ARIN region and that may justifiably require numbered resources from ARIN. This approach is very similar to the practical method that courts typically apply to assess whether parties have a sufficient connection to a jurisdiction so as to require them to submit themselves to the courts of that jurisdiction. This draft policy is a substantial improvement over the previous version of ARIN-2014-1 in terms of reducing the overall risk to the community by requiring a real and substantial connection between an entity requesting resources and the ARIN region. ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-5 OUT OF REGION USE https://www.arin.net/policy/proposals/2015_5.html Date of Assessment: 18 August 2015 ___ 1. Summary (Staff Understanding) This proposal would allow an organization to receive Internet number resources from ARIN for use out of region as long as the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. In addition, the applicant must have a real and substantial connection with the ARIN region, which the applicant shall be responsible for proving. ___ 2. Comments A. ARIN Staff Comments This policy would increase the complexity of ARIN staff review work in request cases that fit the profile of this policy. There would in an increase in the vetting and utilization verification work currently conducted by ARIN staff. There are conflicting instructions to ARIN staff in this policy text. Specifically, the text says, "The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN." Then at the end of the examples given, the text states, "Any other method that the entity considers appropriate." This implies that ARIN staff may have to accept anything presented by an organization as a method of proving a "real and substantial connection with the ARIN region." It is not clear if the utilized /22, /44 or AS Number are required to have been issued by ARIN or is it allowable to be from another RIR. This policy would be placed in the NRPM as section 9, "Out of Region Use". B. ARIN General Counsel ??? Legal Assessment If the policy is enacted it will require ARIN staff to work with counsel with some attendant increase in costs in the first year to manage implementation. The policy is consistent with standard legal principles routinely utilized in the ARIN region. The policy creates no material legal risks. ___ 3. Resource Impact This policy could have a major resource impact from an implementation aspect. It is estimated that implementation would occur within 12 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training * Engineering: Engineering efforts to handle out of region business rules may besubstantial as our system only supports ascii now. If there is a need for unicode character sets, then there is a substantial amount of work required to upgrade the DB and applications to support unicode. Additionally, we would need to discuss how to display unicode characters in port 43 whois. There may be additional tools needed by RSD staff to measure in region/out of region use. ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2015-5 Date: 23 June 2015 Problem statement: Current policy neither clearly forbids nor clearly permits out or region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. In addition, the applicant must have a real and substantial connection with the ARIN region, which the applicant shall be responsible for proving. A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner, whether for or not for profit. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. * Demonstrating that the entity provides services to or solicits sales from residents of the ARIN region. * Demonstrating that the entity holds annual meetings in the ARIN region. * Demonstrating that the entity raises investment capital from investors in the ARIN region. * Demonstrating that the entity has a registered office in the ARIN region, although this factor on its own shall not be sufficient. * Any other method that the entity considers appropriate. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, the officer of the applicant must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. Comments: a) Timetable for implementation: Various iterations of this policy have been presented and debated by ARIN for well over a year now. Given the amount of time that has already been spent on developing a policy, ideally, this policy would be implemented as soon as possible. b) Explanation of draft policy: The draft policy addresses both the problem statement as well as the concerns raised at ARIN 35 by participants as well as ARIN counsel. Firstly, the draft policy addresses the concerns of ARIN counsel as well as some of the participants at ARIN 35 by ensuring that anyone requesting numbered resources from ARIN has a real and substantial connection with the ARIN region. This should go a long way to addressing concerns about fraud, legal liability, and interference with the jurisdiction of other RIRs. In addition, by placing the burden of proof for demonstrating a real and substantial connection with the ARIN region on the applicant, the amount of work required of ARIN staff to apply the policy will be reduced. The factors noted above are suggestions that an entity may use to demonstrate to ARIN that it is carrying on business in the ARIN region in a meaningful manner. These factors are all indicative, some more than others, that an entity has a real and substantial connection to the ARIN region through the carrying on of business in the ARIN region in a meaningful manner. Not all of the factors will apply in a given case and proving a single factor may not be enough to satisfy ARIN that an entity is carrying on business in the region in a meaningful manner. The list of factors is meant to be quite broad, including an open-ended factor, in order to capture the diversity of businesses that operate in the ARIN region and that may justifiably require numbered resources from ARIN. This approach is very similar to the practical method that courts typically apply to assess whether parties have a sufficient connection to a jurisdiction so as to require them to submit themselves to the courts of that jurisdiction. This draft policy is a substantial improvement over the previous version of ARIN-2014-1 in terms of reducing the overall risk to the community by requiring a real and substantial connection between an entity requesting resources and the ARIN region. From lsawyer at gci.com Wed Sep 9 14:19:17 2015 From: lsawyer at gci.com (Leif Sawyer) Date: Wed, 9 Sep 2015 18:19:17 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy Message-ID: Apologies to the list. The actual text of draft ARIN-2015-3 did not attach correctly. The current draft text can also be located at: https://www.arin.net/policy/proposals/2015_3.html -- Draft Policy ARIN-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy Date: 26 May 2015 Problem Statement: End-user policy is intended to provide end-users with a one year supply of IP addresses. Qualification for a one-year supply requires the network operator to utilize at least 25% of the requested addresses within 30 days. This text is unrealistic and should be removed. First, it often takes longer than 30 days to stage equipment and start actually using the addresses. Second, growth is often not that regimented; the forecast is to use X addresses over the course of a year, not to use 25% of X within 30 days. Third, this policy text applies to additional address space requests. It is incompatible with the requirements of other additional address space request justification which indicates that 80% utilization of existing space is sufficient to justify new space. If a block is at 80%, then often (almost always?) the remaining 80% will be used over the next 30 days and longer. Therefore the operator cannot honestly state they will use 25% of the ADDITIONAL space within 30 days of receiving it; they're still trying to use their older block efficiently. Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give out /24 (or larger) blocks. So the justification for the 25% rule that previously existed (and in fact, applied for many years) is no longer germane. Policy statement: Remove the 25% utilization criteria bullet point from NRPM 4.3.3. Comments: a.Timetable for implementation: Immediate b.Anything else -----Original Message----- From: Leif Sawyer Sent: Tuesday, September 08, 2015 11:10 AM To: arin-ppml at arin.net Subject: Draft Policy ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy ARIN Legal and Staff have conducted a review of Draft Policy 2015-3. ARIN Advisory Council are seeking any additional feedback on this draft policy, prior to public discussion at ARIN 36 in Montreal next month. The text of the staff review is below: ___ Date of Assessment: 18 August 2015 ___ 1. Summary (Staff Understanding) This proposal would remove the 25% utilization (within 30 days of issuance) criteria bullet point from NRPM 4.3.3. ___ 2. Comments A. ARIN Staff Comments This policy would more closely align with the way staff applies the existing policy in relation to 8.3 transfers. Because there is no longer an IPv4 free pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the adoption of this policy should have no major impact on operations and could be implemented as written. Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within 30 days of issuance) requirement. Staff suggests removing the first two sentences of 4.2.3.6 to remove the references to RFC 2050 and the 25% requirement. Additionally, staff suggests removing the reference to the obsolete RFC 2050 in section 4.3.3. B. ARIN General Counsel ? Legal Assessment No material legal risk in this policy. ___ 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur immediately after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training ___ From hannigan at gmail.com Thu Sep 10 17:40:40 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 10 Sep 2015 17:40:40 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: <55F0365D.6010409@arin.net> References: <55F0365D.6010409@arin.net> Message-ID: I use my addresses globally and will continue to do so as needed. I've never needed a policy to tell me I can or can't. Why can't ARIN just confirm that they're a business and be done with it? Isn't this what we pay them for? GOTO 10 Not in favor. Best, -M< On Wed, Sep 9, 2015 at 9:38 AM, ARIN wrote: > ARIN-2015-5 has been revised. > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-5 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > ARIN-2015-5 is below and can be found at: > https://www.arin.net/policy/proposals/2015_5.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2015-5 > Out of region use > > Date: 9 September 2015 > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out of region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on this > issue has explored several options to restrict or otherwise limit out of > region use. None of these options have gained consensus within the > community. The next logical option is a proposal that clearly permits out > of region use while addressing the key concerns expressed about unlimited > openness to out of region use and enables ARIN staff to implement the > policy efficiently. > > Policy statement: > > Create new Section X: ARIN registered resources may be used outside the > ARIN service region. > > Out of region use of ARIN registered resources are valid justification for > additional number resources, provided that the applicant has a real and > substantial connection with the ARIN region which applicant must prove (as > described below) and is using the same type of resources (with a delegation > lineage back to an ARIN allocation or assignment) within the ARIN service > region as follows: > > * IPv4: At least a /22 used in region > * IPv6: At least a /44 used in region > * ASN: At least one ASN present on one or more peering sessions and/or > routers within the region. > > A real and substantial connection shall be defined as carrying on business > in the ARIN region in a meaningful manner, whether for or not for profit. > The determination as to whether an entity is carrying on business in the > ARIN region in a meaningful manner shall be made by ARIN. Simply being > incorporated in the ARIN region shall not be sufficient, on its own, to > prove that an entity is carrying on business in the ARIN region in a > meaningful manner. Methods that entities may consider using, including > cumulatively, to prove that they are carrying on business in the ARIN > region in a meaningful manner include: > * Demonstrating a physical presence in the ARIN region through a bricks > and mortar location that is actually used for the purposes of conducting > business in the ARIN region in a meaningful manner. That is to say, the > location is not merely a registered office that serves no other business > purpose. > * Demonstrating that the entity has staff in the ARIN region. The greater > the number of staff, the stronger this connecting factor is. > * Demonstrating that the entity holds assets in the ARIN region. The > greater the asset value, the stronger this connecting factor is. > * Demonstrating that the entity provides services to or solicits sales > from residents of the ARIN region. > * Demonstrating that the entity holds annual meetings in the ARIN region. > * Demonstrating that the entity raises investment capital from investors > in the ARIN region. > * Demonstrating that the entity has a registered office in the ARIN > region, although this factor on its own shall not be sufficient. > * Any other method that the entity considers appropriate. > The weight accorded to any of the above-noted factors, if any, shall be > determined solely by ARIN. > > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR's service region, an officer > of the application must attest that the same services and facilities have > not been used as the basis for a resource request in the other region(s). > ARIN reserves the right to request a listing of all the applicant's number > holdings in the region(s) of proposed use, but this should happen only when > there are significant reasons to suspect duplicate requests. > > Comments: > > a) Timetable for implementation: Various iterations of this policy have > been presented and debated by ARIN for well over a year now. Given the > amount of time that has already been spent on developing a policy, ideally, > this policy would be implemented as soon as possible. > b) Explanation of draft policy: The draft policy addresses both the > problem statement as well as the concerns raised at ARIN 35 by participants > as well as ARIN counsel. > Firstly, the draft policy addresses the concerns of ARIN counsel as well > as some of the participants at ARIN 35 by ensuring that anyone requesting > numbered resources from ARIN has a real and substantial connection with the > ARIN region. This should go a long way to addressing concerns about fraud, > legal liability, and interference with the jurisdiction of other RIRs. > In addition, by placing the burden of proof for demonstrating a real and > substantial connection with the ARIN region on the applicant, the amount of > work required of ARIN staff to apply the policy will be reduced. > The factors noted above are suggestions that an entity may use to > demonstrate to ARIN that it is carrying on business in the ARIN region in a > meaningful manner. These factors are all indicative, some more than others, > that an entity has a real and substantial connection to the ARIN region > through the carrying on of business in the ARIN region in a meaningful > manner. Not all of the factors will apply in a given case and proving a > single factor may not be enough to satisfy ARIN that an entity is carrying > on business in the region in a meaningful manner. The list of factors is > meant to be quite broad, including an open-ended factor, in order to > capture the diversity of businesses that operate in the ARIN region and > that may justifiably require numbered resources from ARIN. This approach is > very similar to the practical method that courts typically apply to assess > whether parties have a sufficient connection to a jurisdiction so as to > require them to submit themselves to the courts of that jurisdiction. > > This draft policy is a substantial improvement over the previous version > of ARIN-2014-1 in terms of reducing the overall risk to the community by > requiring a real and substantial connection between an entity requesting > resources and the ARIN region. > > ##### > > ARIN STAFF & LEGAL ASSESSMENT > > Draft Policy ARIN-2015-5 > OUT OF REGION USE > https://www.arin.net/policy/proposals/2015_5.html > > Date of Assessment: 18 August 2015 > > ___ > 1. Summary (Staff Understanding) > > This proposal would allow an organization to receive Internet number > resources from ARIN for use out of region as long as the applicant is > currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 > ASN within the ARIN service region, respectively. In addition, the > applicant must have a real and substantial connection with the ARIN region, > which the applicant shall be responsible for proving. > > ___ > 2. Comments > > A. ARIN Staff Comments > > This policy would increase the complexity of ARIN staff review work in > request cases that fit the profile of this policy. There would in an > increase in the vetting and utilization verification work currently > conducted by ARIN staff. > > There are conflicting instructions to ARIN staff in this policy text. > Specifically, the text says, "The determination as to whether an entity is > carrying on business in the ARIN region in a meaningful manner shall be > made by ARIN." Then at the end of the examples given, the text states, "Any > other method that the entity considers appropriate." This implies that ARIN > staff may have to accept anything presented by an organization as a method > of proving a "real and substantial connection with the ARIN region." > > It is not clear if the utilized /22, /44 or AS Number are required to have > been issued by ARIN or is it allowable to be from another RIR. > > This policy would be placed in the NRPM as section 9, "Out of Region Use". > > B. ARIN General Counsel ??? Legal Assessment > > If the policy is enacted it will require ARIN staff to work with counsel > with some attendant increase in costs in the first year to manage > implementation. The policy is consistent with standard legal principles > routinely utilized in the ARIN region. The policy creates no material legal > risks. > > ___ > 3. Resource Impact > This policy could have a major resource impact from an implementation > aspect. It is estimated that implementation would occur within 12 months > after ratification by the ARIN Board of Trustees. The following would be > needed in order to implement: > > * Updated guidelines and internal procedures > * Staff training > * Engineering: Engineering efforts to handle out of region business rules > may besubstantial as our system only supports ascii now. If there is a need > for unicode character sets, then there is a substantial amount of work > required to upgrade the DB and applications to support unicode. > Additionally, we would need to discuss how to display unicode characters in > port 43 whois. There may be additional tools needed by RSD staff to measure > in region/out of region use. > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2015-5 > > Date: 23 June 2015 > > Problem statement: > Current policy neither clearly forbids nor clearly permits out or region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on this > issue has explored several options to restrict or otherwise limit out of > region use. None of these options have gained consensus within the > community. The next logical option is a proposal that clearly permits out > of region use while addressing the key concerns expressed about unlimited > openness to out of region use and enables ARIN staff to implement the > policy efficiently. > > Policy statement: > Create new Section X: > ARIN registered resources may be used outside the ARIN service region. Out > of region use of IPv4, IPv6, or ASNs are valid justification for additional > number resources if the applicant is currently using at least the > equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service > region, respectively. In addition, the applicant must have a real and > substantial connection with the ARIN region, which the applicant shall be > responsible for proving. > A real and substantial connection shall be defined as carrying on business > in the ARIN region in a meaningful manner, whether for or not for profit. > The determination as to whether an entity is carrying on business in the > ARIN region in a meaningful manner shall be made by ARIN. Simply being > incorporated in the ARIN region shall not be sufficient, on its own, to > prove that an entity is carrying on business in the ARIN region in a > meaningful manner. Methods that entities may consider using, including > cumulatively, to prove that they are carrying on business in the ARIN > region in a meaningful manner include: > * Demonstrating a physical presence in the ARIN region through a bricks > and mortar location that is actually used for the purposes of conducting > business in the ARIN region in a meaningful manner. That is to say, the > location is not merely a registered office that serves no other business > purpose. > * Demonstrating that the entity has staff in the ARIN region. The greater > the number of staff, the stronger this connecting factor is. > * Demonstrating that the entity holds assets in the ARIN region. The > greater the asset value, the stronger this connecting factor is. > * Demonstrating that the entity provides services to or solicits sales > from residents of the ARIN region. > * Demonstrating that the entity holds annual meetings in the ARIN region. > * Demonstrating that the entity raises investment capital from investors > in the ARIN region. > * Demonstrating that the entity has a registered office in the ARIN > region, although this factor on its own shall not be sufficient. > * Any other method that the entity considers appropriate. > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR's service region, the officer > of the applicant must attest that the same services and facilities have not > been used as the basis for a resource request in the other region(s). ARIN > reserves the right to request a listing of all the applicant's number > holdings in the region(s) of proposed use, but this should happen only when > there are significant reasons to suspect duplicate requests. > > Comments: > a) Timetable for implementation: Various iterations of this policy have > been presented and debated by ARIN for well over a year now. Given the > amount of time that has already been spent on developing a policy, ideally, > this policy would be implemented as soon as possible. > b) Explanation of draft policy: The draft policy addresses both the > problem statement as well as the concerns raised at ARIN 35 by participants > as well as ARIN counsel. > Firstly, the draft policy addresses the concerns of ARIN counsel as well > as some of the participants at ARIN 35 by ensuring that anyone requesting > numbered resources from ARIN has a real and substantial connection with the > ARIN region. This should go a long way to addressing concerns about fraud, > legal liability, and interference with the jurisdiction of other RIRs. > In addition, by placing the burden of proof for demonstrating a real and > substantial connection with the ARIN region on the applicant, the amount of > work required of ARIN staff to apply the policy will be reduced. > The factors noted above are suggestions that an entity may use to > demonstrate to ARIN that it is carrying on business in the ARIN region in a > meaningful manner. These factors are all indicative, some more than others, > that an entity has a real and substantial connection to the ARIN region > through the carrying on of business in the ARIN region in a meaningful > manner. Not all of the factors will apply in a given case and proving a > single factor may not be enough to satisfy ARIN that an entity is carrying > on business in the region in a meaningful manner. The list of factors is > meant to be quite broad, including an open-ended factor, in order to > capture the diversity of businesses that operate in the ARIN region and > that may justifiably require numbered resources from ARIN. This approach is > very similar to the practical method that courts typically apply to assess > whether parties have a sufficient connection to a jurisdiction so as to > require them to submit themselves to the courts of that jurisdiction. > This draft policy is a substantial improvement over the previous version > of ARIN-2014-1 in terms of reducing the overall risk to the community by > requiring a real and substantial connection between an entity requesting > resources and the ARIN region. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 matthew at matthew.at Thu Sep 10 18:03:57 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 10 Sep 2015 15:03:57 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: References: <55F0365D.6010409@arin.net> Message-ID: <55F1FE4D.3060508@matthew.at> On 9/10/2015 2:40 PM, Martin Hannigan wrote: > > I use my addresses globally and will continue to do so as needed. > I've never needed a policy to tell me I can or can't. +1 As I've said before, isn't the whole point of the Internet that geography can become largely irrelevant. Like I can take a disaster hit in California and spin up the standby VMs that are in London, adjust a little BGP, and keep rolling... why would where I happen to be using a particular address today be ARIN's business at all? Matthew Kaufman From scottleibrand at gmail.com Thu Sep 10 20:30:32 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 10 Sep 2015 17:30:32 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: References: <55F0365D.6010409@arin.net> Message-ID: On Thu, Sep 10, 2015 at 2:40 PM, Martin Hannigan wrote: > > I use my addresses globally and will continue to do so as needed. I've > never needed a policy to tell me I can or can't. > > Why can't ARIN just confirm that they're a business and be done with it? > Isn't this what we pay them for? > ARIN staff has indicated that a policy like this one is required for them to stop interpreting ICP-2 as requiring in-region use of addresses. In other words, you may not have needed a policy to use your addresses globally, but ARIN has indicated they do need a policy for others to do so. > GOTO 10 > > Not in favor. > Do you have any arguments against the proposal? "I've never needed a policy to tell me I can use my addresses globally" doesn't seem sufficient to me as reason to oppose it, particularly since others have not been able to do so. -Scott > On Wed, Sep 9, 2015 at 9:38 AM, ARIN wrote: > >> ARIN-2015-5 has been revised. >> >> You are encouraged to discuss the merits and your concerns of Draft >> Policy 2015-5 on the Public Policy Mailing List. >> >> The AC will evaluate the discussion in order to assess the conformance >> of this draft policy with ARIN's Principles of Internet Number Resource >> Policy as stated in the PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> ARIN-2015-5 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_5.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy ARIN-2015-5 >> Out of region use >> >> Date: 9 September 2015 >> >> Problem statement: >> >> Current policy neither clearly forbids nor clearly permits out of region >> use of ARIN registered resources. This has created confusion and >> controversy within the ARIN community for some time. Earlier work on this >> issue has explored several options to restrict or otherwise limit out of >> region use. None of these options have gained consensus within the >> community. The next logical option is a proposal that clearly permits out >> of region use while addressing the key concerns expressed about unlimited >> openness to out of region use and enables ARIN staff to implement the >> policy efficiently. >> >> Policy statement: >> >> Create new Section X: ARIN registered resources may be used outside the >> ARIN service region. >> >> Out of region use of ARIN registered resources are valid justification >> for additional number resources, provided that the applicant has a real and >> substantial connection with the ARIN region which applicant must prove (as >> described below) and is using the same type of resources (with a delegation >> lineage back to an ARIN allocation or assignment) within the ARIN service >> region as follows: >> >> * IPv4: At least a /22 used in region >> * IPv6: At least a /44 used in region >> * ASN: At least one ASN present on one or more peering sessions and/or >> routers within the region. >> >> A real and substantial connection shall be defined as carrying on >> business in the ARIN region in a meaningful manner, whether for or not for >> profit. The determination as to whether an entity is carrying on business >> in the ARIN region in a meaningful manner shall be made by ARIN. Simply >> being incorporated in the ARIN region shall not be sufficient, on its own, >> to prove that an entity is carrying on business in the ARIN region in a >> meaningful manner. Methods that entities may consider using, including >> cumulatively, to prove that they are carrying on business in the ARIN >> region in a meaningful manner include: >> * Demonstrating a physical presence in the ARIN region through a bricks >> and mortar location that is actually used for the purposes of conducting >> business in the ARIN region in a meaningful manner. That is to say, the >> location is not merely a registered office that serves no other business >> purpose. >> * Demonstrating that the entity has staff in the ARIN region. The greater >> the number of staff, the stronger this connecting factor is. >> * Demonstrating that the entity holds assets in the ARIN region. The >> greater the asset value, the stronger this connecting factor is. >> * Demonstrating that the entity provides services to or solicits sales >> from residents of the ARIN region. >> * Demonstrating that the entity holds annual meetings in the ARIN region. >> * Demonstrating that the entity raises investment capital from investors >> in the ARIN region. >> * Demonstrating that the entity has a registered office in the ARIN >> region, although this factor on its own shall not be sufficient. >> * Any other method that the entity considers appropriate. >> The weight accorded to any of the above-noted factors, if any, shall be >> determined solely by ARIN. >> >> The services and facilities used to justify the need for ARIN resources >> that will be used out of region cannot also be used to justify resource >> requests from another RIR. When a request for resources from ARIN is >> justified by need located within another RIR's service region, an officer >> of the application must attest that the same services and facilities have >> not been used as the basis for a resource request in the other region(s). >> ARIN reserves the right to request a listing of all the applicant's number >> holdings in the region(s) of proposed use, but this should happen only when >> there are significant reasons to suspect duplicate requests. >> >> Comments: >> >> a) Timetable for implementation: Various iterations of this policy have >> been presented and debated by ARIN for well over a year now. Given the >> amount of time that has already been spent on developing a policy, ideally, >> this policy would be implemented as soon as possible. >> b) Explanation of draft policy: The draft policy addresses both the >> problem statement as well as the concerns raised at ARIN 35 by participants >> as well as ARIN counsel. >> Firstly, the draft policy addresses the concerns of ARIN counsel as well >> as some of the participants at ARIN 35 by ensuring that anyone requesting >> numbered resources from ARIN has a real and substantial connection with the >> ARIN region. This should go a long way to addressing concerns about fraud, >> legal liability, and interference with the jurisdiction of other RIRs. >> In addition, by placing the burden of proof for demonstrating a real and >> substantial connection with the ARIN region on the applicant, the amount of >> work required of ARIN staff to apply the policy will be reduced. >> The factors noted above are suggestions that an entity may use to >> demonstrate to ARIN that it is carrying on business in the ARIN region in a >> meaningful manner. These factors are all indicative, some more than others, >> that an entity has a real and substantial connection to the ARIN region >> through the carrying on of business in the ARIN region in a meaningful >> manner. Not all of the factors will apply in a given case and proving a >> single factor may not be enough to satisfy ARIN that an entity is carrying >> on business in the region in a meaningful manner. The list of factors is >> meant to be quite broad, including an open-ended factor, in order to >> capture the diversity of businesses that operate in the ARIN region and >> that may justifiably require numbered resources from ARIN. This approach is >> very similar to the practical method that courts typically apply to assess >> whether parties have a sufficient connection to a jurisdiction so as to >> require them to submit themselves to the courts of that jurisdiction. >> >> This draft policy is a substantial improvement over the previous version >> of ARIN-2014-1 in terms of reducing the overall risk to the community by >> requiring a real and substantial connection between an entity requesting >> resources and the ARIN region. >> >> ##### >> >> ARIN STAFF & LEGAL ASSESSMENT >> >> Draft Policy ARIN-2015-5 >> OUT OF REGION USE >> https://www.arin.net/policy/proposals/2015_5.html >> >> Date of Assessment: 18 August 2015 >> >> ___ >> 1. Summary (Staff Understanding) >> >> This proposal would allow an organization to receive Internet number >> resources from ARIN for use out of region as long as the applicant is >> currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 >> ASN within the ARIN service region, respectively. In addition, the >> applicant must have a real and substantial connection with the ARIN region, >> which the applicant shall be responsible for proving. >> >> ___ >> 2. Comments >> >> A. ARIN Staff Comments >> >> This policy would increase the complexity of ARIN staff review work in >> request cases that fit the profile of this policy. There would in an >> increase in the vetting and utilization verification work currently >> conducted by ARIN staff. >> >> There are conflicting instructions to ARIN staff in this policy text. >> Specifically, the text says, "The determination as to whether an entity is >> carrying on business in the ARIN region in a meaningful manner shall be >> made by ARIN." Then at the end of the examples given, the text states, "Any >> other method that the entity considers appropriate." This implies that ARIN >> staff may have to accept anything presented by an organization as a method >> of proving a "real and substantial connection with the ARIN region." >> >> It is not clear if the utilized /22, /44 or AS Number are required to >> have been issued by ARIN or is it allowable to be from another RIR. >> >> This policy would be placed in the NRPM as section 9, "Out of Region Use". >> >> B. ARIN General Counsel ??? Legal Assessment >> >> If the policy is enacted it will require ARIN staff to work with counsel >> with some attendant increase in costs in the first year to manage >> implementation. The policy is consistent with standard legal principles >> routinely utilized in the ARIN region. The policy creates no material legal >> risks. >> >> ___ >> 3. Resource Impact >> This policy could have a major resource impact from an implementation >> aspect. It is estimated that implementation would occur within 12 months >> after ratification by the ARIN Board of Trustees. The following would be >> needed in order to implement: >> >> * Updated guidelines and internal procedures >> * Staff training >> * Engineering: Engineering efforts to handle out of region business rules >> may besubstantial as our system only supports ascii now. If there is a need >> for unicode character sets, then there is a substantial amount of work >> required to upgrade the DB and applications to support unicode. >> Additionally, we would need to discuss how to display unicode characters in >> port 43 whois. There may be additional tools needed by RSD staff to measure >> in region/out of region use. >> >> ___ >> 4. Proposal / Draft Policy Text Assessed >> >> Draft Policy ARIN-2015-5 >> >> Date: 23 June 2015 >> >> Problem statement: >> Current policy neither clearly forbids nor clearly permits out or region >> use of ARIN registered resources. This has created confusion and >> controversy within the ARIN community for some time. Earlier work on this >> issue has explored several options to restrict or otherwise limit out of >> region use. None of these options have gained consensus within the >> community. The next logical option is a proposal that clearly permits out >> of region use while addressing the key concerns expressed about unlimited >> openness to out of region use and enables ARIN staff to implement the >> policy efficiently. >> >> Policy statement: >> Create new Section X: >> ARIN registered resources may be used outside the ARIN service region. >> Out of region use of IPv4, IPv6, or ASNs are valid justification for >> additional number resources if the applicant is currently using at least >> the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN >> service region, respectively. In addition, the applicant must have a real >> and substantial connection with the ARIN region, which the applicant shall >> be responsible for proving. >> A real and substantial connection shall be defined as carrying on >> business in the ARIN region in a meaningful manner, whether for or not for >> profit. The determination as to whether an entity is carrying on business >> in the ARIN region in a meaningful manner shall be made by ARIN. Simply >> being incorporated in the ARIN region shall not be sufficient, on its own, >> to prove that an entity is carrying on business in the ARIN region in a >> meaningful manner. Methods that entities may consider using, including >> cumulatively, to prove that they are carrying on business in the ARIN >> region in a meaningful manner include: >> * Demonstrating a physical presence in the ARIN region through a bricks >> and mortar location that is actually used for the purposes of conducting >> business in the ARIN region in a meaningful manner. That is to say, the >> location is not merely a registered office that serves no other business >> purpose. >> * Demonstrating that the entity has staff in the ARIN region. The greater >> the number of staff, the stronger this connecting factor is. >> * Demonstrating that the entity holds assets in the ARIN region. The >> greater the asset value, the stronger this connecting factor is. >> * Demonstrating that the entity provides services to or solicits sales >> from residents of the ARIN region. >> * Demonstrating that the entity holds annual meetings in the ARIN region. >> * Demonstrating that the entity raises investment capital from investors >> in the ARIN region. >> * Demonstrating that the entity has a registered office in the ARIN >> region, although this factor on its own shall not be sufficient. >> * Any other method that the entity considers appropriate. >> The services and facilities used to justify the need for ARIN resources >> that will be used out of region cannot also be used to justify resource >> requests from another RIR. When a request for resources from ARIN is >> justified by need located within another RIR's service region, the officer >> of the applicant must attest that the same services and facilities have not >> been used as the basis for a resource request in the other region(s). ARIN >> reserves the right to request a listing of all the applicant's number >> holdings in the region(s) of proposed use, but this should happen only when >> there are significant reasons to suspect duplicate requests. >> >> Comments: >> a) Timetable for implementation: Various iterations of this policy have >> been presented and debated by ARIN for well over a year now. Given the >> amount of time that has already been spent on developing a policy, ideally, >> this policy would be implemented as soon as possible. >> b) Explanation of draft policy: The draft policy addresses both the >> problem statement as well as the concerns raised at ARIN 35 by participants >> as well as ARIN counsel. >> Firstly, the draft policy addresses the concerns of ARIN counsel as well >> as some of the participants at ARIN 35 by ensuring that anyone requesting >> numbered resources from ARIN has a real and substantial connection with the >> ARIN region. This should go a long way to addressing concerns about fraud, >> legal liability, and interference with the jurisdiction of other RIRs. >> In addition, by placing the burden of proof for demonstrating a real and >> substantial connection with the ARIN region on the applicant, the amount of >> work required of ARIN staff to apply the policy will be reduced. >> The factors noted above are suggestions that an entity may use to >> demonstrate to ARIN that it is carrying on business in the ARIN region in a >> meaningful manner. These factors are all indicative, some more than others, >> that an entity has a real and substantial connection to the ARIN region >> through the carrying on of business in the ARIN region in a meaningful >> manner. Not all of the factors will apply in a given case and proving a >> single factor may not be enough to satisfy ARIN that an entity is carrying >> on business in the region in a meaningful manner. The list of factors is >> meant to be quite broad, including an open-ended factor, in order to >> capture the diversity of businesses that operate in the ARIN region and >> that may justifiably require numbered resources from ARIN. This approach is >> very similar to the practical method that courts typically apply to assess >> whether parties have a sufficient connection to a jurisdiction so as to >> require them to submit themselves to the courts of that jurisdiction. >> This draft policy is a substantial improvement over the previous version >> of ARIN-2014-1 in terms of reducing the overall risk to the community by >> requiring a real and substantial connection between an entity requesting >> resources and the ARIN region. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Thu Sep 10 20:48:20 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 10 Sep 2015 20:48:20 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: References: <55F0365D.6010409@arin.net> Message-ID: > On Sep 10, 2015, at 20:30, Scott Leibrand wrote: > >> On Thu, Sep 10, 2015 at 2:40 PM, Martin Hannigan wrote: >> >> I use my addresses globally and will continue to do so as needed. I've never needed a policy to tell me I can or can't. >> >> Why can't ARIN just confirm that they're a business and be done with it? Isn't this what we pay them for? > > ARIN staff has indicated that a policy like this one is required for them to stop interpreting ICP-2 as requiring in-region use of addresses. In other words, you may not have needed a policy to use your addresses globally, but ARIN has indicated they do need a policy for others to do so. > >> >> GOTO 10 >> >> Not in favor. > > Do you have any arguments against the proposal? "I've never needed a policy to tell me I can use my addresses globally" doesn't seem sufficient to me as reason to oppose it, particularly since others have not been able to do so. > > -Scott > Obviously that argument falls flat. See ASN 20940. And others. I've been perfectly clear in my "needs" statement as to where I'm deploying requested numbers on day one. Globally. ARIN assigning inconsistently is a staff problem, not a policy issue isn't it? Do you have any _credible arguments for the proposal? This one is as weak as the last four? attempts. Best, -M< >>> On Wed, Sep 9, 2015 at 9:38 AM, ARIN wrote: >>> ARIN-2015-5 has been revised. >>> >>> You are encouraged to discuss the merits and your concerns of Draft >>> Policy 2015-5 on the Public Policy Mailing List. >>> >>> The AC will evaluate the discussion in order to assess the conformance >>> of this draft policy with ARIN's Principles of Internet Number Resource >>> Policy as stated in the PDP. Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> ARIN-2015-5 is below and can be found at: >>> https://www.arin.net/policy/proposals/2015_5.html >>> >>> Regards, >>> >>> Communications and Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> Draft Policy ARIN-2015-5 >>> Out of region use >>> >>> Date: 9 September 2015 >>> >>> Problem statement: >>> >>> Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. >>> >>> Policy statement: >>> >>> Create new Section X: ARIN registered resources may be used outside the ARIN service region. >>> >>> Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows: >>> >>> * IPv4: At least a /22 used in region >>> * IPv6: At least a /44 used in region >>> * ASN: At least one ASN present on one or more peering sessions and/or routers within the region. >>> >>> A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner, whether for or not for profit. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: >>> * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. >>> * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. >>> * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. >>> * Demonstrating that the entity provides services to or solicits sales from residents of the ARIN region. >>> * Demonstrating that the entity holds annual meetings in the ARIN region. >>> * Demonstrating that the entity raises investment capital from investors in the ARIN region. >>> * Demonstrating that the entity has a registered office in the ARIN region, although this factor on its own shall not be sufficient. >>> * Any other method that the entity considers appropriate. >>> The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN. >>> >>> The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. >>> >>> Comments: >>> >>> a) Timetable for implementation: Various iterations of this policy have been presented and debated by ARIN for well over a year now. Given the amount of time that has already been spent on developing a policy, ideally, this policy would be implemented as soon as possible. >>> b) Explanation of draft policy: The draft policy addresses both the problem statement as well as the concerns raised at ARIN 35 by participants as well as ARIN counsel. >>> Firstly, the draft policy addresses the concerns of ARIN counsel as well as some of the participants at ARIN 35 by ensuring that anyone requesting numbered resources from ARIN has a real and substantial connection with the ARIN region. This should go a long way to addressing concerns about fraud, legal liability, and interference with the jurisdiction of other RIRs. >>> In addition, by placing the burden of proof for demonstrating a real and substantial connection with the ARIN region on the applicant, the amount of work required of ARIN staff to apply the policy will be reduced. >>> The factors noted above are suggestions that an entity may use to demonstrate to ARIN that it is carrying on business in the ARIN region in a meaningful manner. These factors are all indicative, some more than others, that an entity has a real and substantial connection to the ARIN region through the carrying on of business in the ARIN region in a meaningful manner. Not all of the factors will apply in a given case and proving a single factor may not be enough to satisfy ARIN that an entity is carrying on business in the region in a meaningful manner. The list of factors is meant to be quite broad, including an open-ended factor, in order to capture the diversity of businesses that operate in the ARIN region and that may justifiably require numbered resources from ARIN. This approach is very similar to the practical method that courts typically apply to assess whether parties have a sufficient connection to a jurisdiction so as to require them to submit themselves to the courts of that jurisdiction. >>> >>> This draft policy is a substantial improvement over the previous version of ARIN-2014-1 in terms of reducing the overall risk to the community by requiring a real and substantial connection between an entity requesting resources and the ARIN region. >>> >>> ##### >>> >>> ARIN STAFF & LEGAL ASSESSMENT >>> >>> Draft Policy ARIN-2015-5 >>> OUT OF REGION USE >>> https://www.arin.net/policy/proposals/2015_5.html >>> >>> Date of Assessment: 18 August 2015 >>> >>> ___ >>> 1. Summary (Staff Understanding) >>> >>> This proposal would allow an organization to receive Internet number resources from ARIN for use out of region as long as the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. In addition, the applicant must have a real and substantial connection with the ARIN region, which the applicant shall be responsible for proving. >>> >>> ___ >>> 2. Comments >>> >>> A. ARIN Staff Comments >>> >>> This policy would increase the complexity of ARIN staff review work in request cases that fit the profile of this policy. There would in an increase in the vetting and utilization verification work currently conducted by ARIN staff. >>> >>> There are conflicting instructions to ARIN staff in this policy text. Specifically, the text says, "The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN." Then at the end of the examples given, the text states, "Any other method that the entity considers appropriate." This implies that ARIN staff may have to accept anything presented by an organization as a method of proving a "real and substantial connection with the ARIN region." >>> >>> It is not clear if the utilized /22, /44 or AS Number are required to have been issued by ARIN or is it allowable to be from another RIR. >>> >>> This policy would be placed in the NRPM as section 9, "Out of Region Use". >>> >>> B. ARIN General Counsel ??? Legal Assessment >>> >>> If the policy is enacted it will require ARIN staff to work with counsel with some attendant increase in costs in the first year to manage implementation. The policy is consistent with standard legal principles routinely utilized in the ARIN region. The policy creates no material legal risks. >>> >>> ___ >>> 3. Resource Impact >>> This policy could have a major resource impact from an implementation aspect. It is estimated that implementation would occur within 12 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: >>> >>> * Updated guidelines and internal procedures >>> * Staff training >>> * Engineering: Engineering efforts to handle out of region business rules may besubstantial as our system only supports ascii now. If there is a need for unicode character sets, then there is a substantial amount of work required to upgrade the DB and applications to support unicode. Additionally, we would need to discuss how to display unicode characters in port 43 whois. There may be additional tools needed by RSD staff to measure in region/out of region use. >>> >>> ___ >>> 4. Proposal / Draft Policy Text Assessed >>> >>> Draft Policy ARIN-2015-5 >>> >>> Date: 23 June 2015 >>> >>> Problem statement: >>> Current policy neither clearly forbids nor clearly permits out or region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. >>> >>> Policy statement: >>> Create new Section X: >>> ARIN registered resources may be used outside the ARIN service region. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. In addition, the applicant must have a real and substantial connection with the ARIN region, which the applicant shall be responsible for proving. >>> A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner, whether for or not for profit. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: >>> * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. >>> * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. >>> * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. >>> * Demonstrating that the entity provides services to or solicits sales from residents of the ARIN region. >>> * Demonstrating that the entity holds annual meetings in the ARIN region. >>> * Demonstrating that the entity raises investment capital from investors in the ARIN region. >>> * Demonstrating that the entity has a registered office in the ARIN region, although this factor on its own shall not be sufficient. >>> * Any other method that the entity considers appropriate. >>> The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, the officer of the applicant must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. >>> >>> Comments: >>> a) Timetable for implementation: Various iterations of this policy have been presented and debated by ARIN for well over a year now. Given the amount of time that has already been spent on developing a policy, ideally, this policy would be implemented as soon as possible. >>> b) Explanation of draft policy: The draft policy addresses both the problem statement as well as the concerns raised at ARIN 35 by participants as well as ARIN counsel. >>> Firstly, the draft policy addresses the concerns of ARIN counsel as well as some of the participants at ARIN 35 by ensuring that anyone requesting numbered resources from ARIN has a real and substantial connection with the ARIN region. This should go a long way to addressing concerns about fraud, legal liability, and interference with the jurisdiction of other RIRs. >>> In addition, by placing the burden of proof for demonstrating a real and substantial connection with the ARIN region on the applicant, the amount of work required of ARIN staff to apply the policy will be reduced. >>> The factors noted above are suggestions that an entity may use to demonstrate to ARIN that it is carrying on business in the ARIN region in a meaningful manner. These factors are all indicative, some more than others, that an entity has a real and substantial connection to the ARIN region through the carrying on of business in the ARIN region in a meaningful manner. Not all of the factors will apply in a given case and proving a single factor may not be enough to satisfy ARIN that an entity is carrying on business in the region in a meaningful manner. The list of factors is meant to be quite broad, including an open-ended factor, in order to capture the diversity of businesses that operate in the ARIN region and that may justifiably require numbered resources from ARIN. This approach is very similar to the practical method that courts typically apply to assess whether parties have a sufficient connection to a jurisdiction so as to require them to submit themselves to the courts of that jurisdiction. >>> This draft policy is a substantial improvement over the previous version of ARIN-2014-1 in terms of reducing the overall risk to the community by requiring a real and substantial connection between an entity requesting resources and the ARIN region. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjletts at uw.edu Thu Sep 10 21:07:38 2015 From: rjletts at uw.edu (Richard J. Letts) Date: Fri, 11 Sep 2015 01:07:38 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: <55F0365D.6010409@arin.net> References: <55F0365D.6010409@arin.net> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: 9 September 2015 6:39 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised > > Current policy neither clearly forbids nor clearly permits out of region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on this > issue has explored several options to restrict or otherwise limit out of > region use. None of these options have gained consensus within the > community. The next logical option is a proposal that clearly permits out > of region use while addressing the key concerns expressed about unlimited > openness to out of region use and enables ARIN staff to implement the > policy efficiently. I'm sorry but I don't see that lack of consensus on restriction means that you are going to be more successful in getting consensus on permission, nor that that is a logical option. What problem are you trying to solve? Why is having an area of doubt and uncertainty causing an operational difficulty for the community, or ARIN staff? Note: confusion and controversy in of itself doesn't mandate finding a solution... that sounds more like politics to me This seems like policy making for the sake of it. > A real and substantial connection shall be defined as carrying on business > in the ARIN region in a meaningful manner, whether for or not for profit. > The determination as to whether an entity is carrying on business in the > ARIN region in a meaningful manner shall be made by ARIN. Simply being > incorporated in the ARIN region shall not be sufficient, on its own, to > prove that an entity is carrying on business in the ARIN region in a > meaningful manner. Methods that entities may consider using, including > cumulatively, to prove that they are carrying on business in the ARIN > region in a meaningful manner include: > * Demonstrating a physical presence in the ARIN region through a bricks > and mortar location that is actually used for the purposes of conducting > business in the ARIN region in a meaningful manner. That is to say, the > location is not merely a registered office that serves no other business > purpose. > * Demonstrating that the entity has staff in the ARIN region. The greater > the number of staff, the stronger this connecting factor is. > * Demonstrating that the entity holds assets in the ARIN region. The > greater the asset value, the stronger this connecting factor is. > * Demonstrating that the entity provides services to or solicits sales > from residents of the ARIN region. > * Demonstrating that the entity holds annual meetings in the ARIN region. > * Demonstrating that the entity raises investment capital from investors > in the ARIN region. > * Demonstrating that the entity has a registered office in the ARIN > region, although this factor on its own shall not be sufficient. > * Any other method that the entity considers appropriate. > The weight accorded to any of the above-noted factors, if any, shall be > determined solely by ARIN. Wow; really. The first part seems to contain a lot of words and redundancy, the next part requires ARIN staff to exercise a lot of work. You're allowing an applicant to snow you under with irrelevant information, and then allowing ARIN staff to ignore it. Seems like that will generate a lot of controversy when an application is denied under this section. Richard Letts From bill at herrin.us Thu Sep 10 22:06:10 2015 From: bill at herrin.us (William Herrin) Date: Thu, 10 Sep 2015 22:06:10 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: <55F0365D.6010409@arin.net> References: <55F0365D.6010409@arin.net> Message-ID: On Wed, Sep 9, 2015 at 9:38 AM, ARIN wrote: > Draft Policy ARIN-2015-5 > Out of region use I remain OPPOSED to this is well. If you guys really feel a need to work in this space, start on a globally coordinated proposal which facilitates all of the registries acting globally with common rules, not just ARIN. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jlewis at lewis.org Fri Sep 11 00:03:26 2015 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 11 Sep 2015 00:03:26 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: <55F1FE4D.3060508@matthew.at> References: <55F0365D.6010409@arin.net> <55F1FE4D.3060508@matthew.at> Message-ID: On Thu, 10 Sep 2015, Matthew Kaufman wrote: > On 9/10/2015 2:40 PM, Martin Hannigan wrote: >> >> I use my addresses globally and will continue to do so as needed. I've >> never needed a policy to tell me I can or can't. > > +1 > > As I've said before, isn't the whole point of the Internet that geography can > become largely irrelevant. Like I can take a disaster hit in California and > spin up the standby VMs that are in London, adjust a little BGP, and keep > rolling... why would where I happen to be using a particular address today be > ARIN's business at all? Like it or not, current "internal policy" is that your resources used out of region (like to provide IPs for that London POP so it can be reachable when its not using your California IPs) don't count as "utilized", and if you're a US based corp wanting to open a DR POP in London and need IPs for it, ARIN won't allocate them to you [to be used out of region]. Worse, if you weren't aware of this policy at the time, and have used a bunch of ARIN space unicast out of region, you may have difficulties getting approved when applying for more space to be used in-region. Regardless of how and where Martin uses his ARIN IPs, or what you think is or isn't ARIN's business, the current "policy" resulting from a very narrow interpretation of vagueness in the NRPM makes it a PITA for ARIN members to operate global networks. I fear it'll be irrelevant before it can be implemented, but I'm in favor of fixing policy, here and anywhere else needed, to remove the need for ARIN to "interpret" actual policy in ways that screw the members. So, just in case I wasn't clear, I'm in favor of 2015-5. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From narten at us.ibm.com Fri Sep 11 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 11 Sep 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201509110453.t8B4r2H2025372@rotala.raleigh.ibm.com> Total of 10 messages in the last 7 days. script run at: Fri Sep 11 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 2 | 43.75% | 86623 | hannigan at gmail.com 10.00% | 1 | 22.23% | 44006 | scottleibrand at gmail.com 20.00% | 2 | 7.92% | 15689 | lsawyer at gci.com 10.00% | 1 | 10.17% | 20126 | info at arin.net 10.00% | 1 | 6.82% | 13496 | rjletts at uw.edu 10.00% | 1 | 3.52% | 6978 | narten at us.ibm.com 10.00% | 1 | 2.86% | 5654 | bill at herrin.us 10.00% | 1 | 2.73% | 5404 | matthew at matthew.at --------+------+--------+----------+------------------------ 100.00% | 10 |100.00% | 197976 | Total From owen at delong.com Fri Sep 11 18:33:09 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Sep 2015 15:33:09 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: References: <55F0365D.6010409@arin.net> <55F1FE4D.3060508@matthew.at> Message-ID: For those that are wondering if this is a real problem? I quote from a recent ARIN response to a resource transfer preapproval request: In accordance with section 2.2 of the NRPM, ARIN issues number resources for use within its region. Please confirm the requested number resources will be routed within the ARIN region. If one takes this language literally, then the scenario where you have servers in USVI that you are addressing, but your anchor routes are held in upstream routers in Brazil and Uruguay would actually potentially preclude you from getting addresses from ARIN. This policy is, in fact, necessary to constrain ARIN staff and provide a clear mechanism by which ARIN region entities can obtain addresses through ARIN for their network, regardless of how far the footprint of their network extends. We all know that geography != topology. Further, the arbitrary lines drawn on a map with passport control stations sprinkled on either side mean very little to bits flowing through fiber. There are no border guards on the fiber networks, or if there are, they are generally not national border guards anyway. As such, unless you believe this policy causes actual harm, I urge you to support it. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Sep 11 20:26:09 2015 From: jcurran at arin.net (John Curran) Date: Sat, 12 Sep 2015 00:26:09 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: References: <55F0365D.6010409@arin.net> <55F1FE4D.3060508@matthew.at> Message-ID: On Sep 11, 2015, at 6:33 PM, Owen DeLong > wrote: For those that are wondering if this is a real problem? I quote from a recent ARIN response to a resource transfer preapproval request: In accordance with section 2.2 of the NRPM, ARIN issues number resources for use within its region. Please confirm the requested number resources will be routed within the ARIN region. If one takes this language literally, then the scenario where you have servers in USVI that you are addressing, but your anchor routes are held in upstream routers in Brazil and Uruguay would actually potentially preclude you from getting addresses from ARIN. This policy is, in fact, necessary to constrain ARIN staff and provide a clear mechanism by which ARIN region entities can obtain addresses through ARIN for their network, regardless of how far the footprint of their network extends. We all know that geography != topology. Further, the arbitrary lines drawn on a map with passport control stations sprinkled on either side mean very little to bits flowing through fiber. There are no border guards on the fiber networks, or if there are, they are generally not national border guards anyway. As such, unless you believe this policy causes actual harm, I urge you to support it. Owen - While I have no view on the relative merits of the referenced draft policy, I believe your description of ARIN?s present policy implementation in this area is essentially correct (and aligns with what was communicated in the ARIN 31 Policy Experience Report - https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Fri Sep 11 21:47:16 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 11 Sep 2015 21:47:16 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: References: <55F0365D.6010409@arin.net> <55F1FE4D.3060508@matthew.at> Message-ID: <475EA327-712A-45EC-863A-73CE175C6A63@gmail.com> John, I believe its a norm to expect paid staff to be neutral with respect to all proposals as many consensus bodies do. ICANN would be a good reference. Feel free to object. Best, -M< > On Sep 11, 2015, at 20:26, John Curran wrote: > >> On Sep 11, 2015, at 6:33 PM, Owen DeLong wrote: >> >> For those that are wondering if this is a real problem? >> >> I quote from a recent ARIN response to a resource transfer preapproval request: >> >> In accordance with section 2.2 of the NRPM, ARIN issues number resources for use within its region. Please confirm the requested number resources will be routed within the ARIN region. >> >> If one takes this language literally, then the scenario where you have servers in USVI that you are addressing, but your anchor routes are held in upstream routers in Brazil and Uruguay would actually potentially preclude you from getting addresses from ARIN. >> >> This policy is, in fact, necessary to constrain ARIN staff and provide a clear mechanism by which ARIN region entities can obtain addresses through ARIN for their network, regardless of how far the footprint of their network extends. >> >> We all know that geography != topology. Further, the arbitrary lines drawn on a map with passport control stations sprinkled on either side mean very little to bits flowing through fiber. There are no border guards on the fiber networks, or if there are, they are generally not national border guards anyway. >> >> As such, unless you believe this policy causes actual harm, I urge you to support it. > > Owen - > > While I have no view on the relative merits of the referenced draft policy, I believe your > description of ARIN?s present policy implementation in this area is essentially correct > (and aligns with what was communicated in the ARIN 31 Policy Experience Report - > https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf) > > Thanks! > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Sep 11 22:12:07 2015 From: jcurran at arin.net (John Curran) Date: Sat, 12 Sep 2015 02:12:07 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: <475EA327-712A-45EC-863A-73CE175C6A63@gmail.com> References: <55F0365D.6010409@arin.net> <55F1FE4D.3060508@matthew.at> <475EA327-712A-45EC-863A-73CE175C6A63@gmail.com> Message-ID: <88DBF4D9-CFF6-4FAF-9645-6B3288D4F761@arin.net> On Sep 11, 2015, at 9:47 PM, Martin Hannigan > wrote: John, I believe its a norm to expect paid staff to be neutral with respect to all proposals as many consensus bodies do. ICANN would be a good reference. Feel free to object. Martin - If you are implying that my statement (to the effect that Owen?s description of ARIN?s current policy implementation in this area is correct) is somehow advocating a position in favor or opposed to the draft policy under consideration, I?d suggest that you read it again. Thanks! /John John Curran President and CEO ARIN While I have no view on the relative merits of the referenced draft policy, I believe your description of ARIN?s present policy implementation in this area is essentially correct (and aligns with what was communicated in the ARIN 31 Policy Experience Report - https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Sat Sep 12 14:31:54 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 12 Sep 2015 14:31:54 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: <6F725996-347A-40FE-B4D7-E54653D8B08D@delong.com> References: <55F0365D.6010409@arin.net> <55F1FE4D.3060508@matthew.at> <475EA327-712A-45EC-863A-73CE175C6A63@gmail.com> <6F725996-347A-40FE-B4D7-E54653D8B08D@delong.com> Message-ID: On Fri, Sep 11, 2015 at 10:12 PM, John Curran wrote: > On Sep 11, 2015, at 9:47 PM, Martin Hannigan wrote: > > John, > > I believe its a norm to expect paid staff to be neutral with respect to > all proposals as many consensus bodies do. ICANN would be a good > reference. Feel free to object. > > > Martin - > > If you are implying that my statement (to the effect that Owen?s > description of ARIN?s > current policy implementation in this area is correct) is somehow > advocating a position > in favor or opposed to the draft policy under consideration, I?d suggest > that you read it > again. > > Thanks! > /John > > John Curran > President and CEO > ARIN > Hi John, I've read your response, thanks for the suggestion. Back to the proposal. One point that's missed in the conversation is that we've rejected the inverse of this proposal, restricting out of region use, multiple times. This is exactly the same attempt with nothing more than confusing language. The "allow" is actually a set up to "deny", just like the previous attempts. "Flipping the script" into "allow" doesn't change anything. Instead, it creates unnecessary encumbrances to commerce which doesn't hurt any bad actors, it hurts us. Almost every requirement that the proposal makes is easily achieved by the staff using public resources. If the staff suspects that there is an issue with an applicant, ARIN _should_ use our money to flush it out. No policy proposal is needed for ARIN to validate who is a member or who is using our numbers. These are administrative issues that we should not be concerned with. I have never had any of the issues that the "proposal" seeks to resolve in justifying almost a /8 for global use including assigning numbers from ARIN to infrastructure in other regions. I expect that without this proposal I will continue to have no problem. If this proposal does get adopted as policy, I will still have no problem. I can assure you though, that small network operators will have a big problem. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Sat Sep 12 18:47:33 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 12 Sep 2015 18:47:33 -0400 Subject: [arin-ppml] Bot spamming via ppml posts Message-ID: Anyone else getting spam after posting? Since about 6 mos ago. Random. From bill at herrin.us Sat Sep 12 19:17:34 2015 From: bill at herrin.us (William Herrin) Date: Sat, 12 Sep 2015 19:17:34 -0400 Subject: [arin-ppml] Bot spamming via ppml posts In-Reply-To: References: Message-ID: On Sat, Sep 12, 2015 at 6:47 PM, Martin Hannigan wrote: > Anyone else getting spam after posting? Since about 6 mos ago. Random. "Amy" with the half naked photo wants to go on a date with me every time I post to PPML.Usually within minutes. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From alfeh at me.com Sat Sep 12 19:21:30 2015 From: alfeh at me.com (Alfie Cleveland) Date: Sun, 13 Sep 2015 00:21:30 +0100 Subject: [arin-ppml] Unallocated IPs Message-ID: <69D81B64-4577-4D71-845C-275B7BE1C86F@me.com> Hey, I was doing some scanning of IP ranges and it appears that there are hundreds, if not thousands, of /21s and equivalents that are not assigned to anyone, yet do not appear on any ARIN inventory counters. Is this an oversight in the WHOIS or has ARIN 'forgotten' about these ranges? For reference, here are some of the blocks: 206.53.141.0/23 206.53.168.0/21 206.53.200.0/21 206.71.8.0/21 206.71.136.0/21 206.72.216.0/21 206.80.232.0/21 206.81.104.0/21 206.82.104.0/21 206.83.8.0/21 206.83.40.0/21 206.83.136.0/21 206.124.40.0/21 206.127.136.0/21 206.127.168.0/21 Regards, Alfie From David.Huberman at microsoft.com Sat Sep 12 19:24:12 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Sat, 12 Sep 2015 23:24:12 +0000 Subject: [arin-ppml] Unallocated IPs In-Reply-To: <69D81B64-4577-4D71-845C-275B7BE1C86F@me.com> References: <69D81B64-4577-4D71-845C-275B7BE1C86F@me.com> Message-ID: They're probably either: In the returned, revoked, or held buckets (scheduled for reissue per arin's processes); or They don't belong to ARIN and are bits and pieces that belong to a different RIR David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________________ From: arin-ppml-bounces at arin.net on behalf of Alfie Cleveland Sent: Saturday, September 12, 2015 4:21:30 PM To: arin-ppml at arin.net Subject: [arin-ppml] Unallocated IPs Hey, I was doing some scanning of IP ranges and it appears that there are hundreds, if not thousands, of /21s and equivalents that are not assigned to anyone, yet do not appear on any ARIN inventory counters. Is this an oversight in the WHOIS or has ARIN 'forgotten' about these ranges? For reference, here are some of the blocks: https://na01.safelinks.protection.outlook.com/?url=206.53.141.0%2f23&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=b7GuMqK1CwA5vdJnij%2bBvoZPhqf5IPhTBFp4sKr%2fFb8%3d https://na01.safelinks.protection.outlook.com/?url=206.53.168.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=C3Ubpm8P3KOF4aDZotwx0jOVcmqg%2fqC7dBt7Dn0EB4c%3d https://na01.safelinks.protection.outlook.com/?url=206.53.200.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QyYU65jl%2f%2fntIdVMf%2f5AUtL7ALpxhoNSN0NEP8Yrz8c%3d https://na01.safelinks.protection.outlook.com/?url=206.71.8.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CDMeW5wHGzMrmS2x%2fmxUqD%2bDPSDVqsL7nNbtpyD8vl4%3d https://na01.safelinks.protection.outlook.com/?url=206.71.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=M0TR90y9HYivk36wrb8QN1XFNztKGD5Ecz%2bM9I%2bsRWY%3d https://na01.safelinks.protection.outlook.com/?url=206.72.216.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mJ3e%2fwyRzHNUGxdueGtezBvx2OH7qiU2%2fgrQs8MIyP0%3d https://na01.safelinks.protection.outlook.com/?url=206.80.232.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pd35AdjesrN6OMfmqojmC%2btr5G7ExF71qsNiB%2fQtoGE%3d https://na01.safelinks.protection.outlook.com/?url=206.81.104.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=imEV3BdewVtbiOnYHdjWu2beDcGKzRIdK%2fYUwkyVqRs%3d https://na01.safelinks.protection.outlook.com/?url=206.82.104.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ck6q0CAMoEqf%2bfNJ7ngLUl75g86lJROoQB6z%2bkf5ios%3d https://na01.safelinks.protection.outlook.com/?url=206.83.8.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MG%2bUxFTi5kUoZAS%2blRnJUp2jH3fL5N8IKkSjIpHACgc%3d https://na01.safelinks.protection.outlook.com/?url=206.83.40.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=S2EyD7tBXpbmB94vNlY6q%2bJctbSVmX7Mcavuzu6wc%2b4%3d https://na01.safelinks.protection.outlook.com/?url=206.83.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uzQ81%2boxJhuEy1chzKIuDDwYNM0zAYQ7jDVt2jMK0w4%3d https://na01.safelinks.protection.outlook.com/?url=206.124.40.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=soN9gJHRPHxND0U3M%2fWgmiPtIwP5s9BTqLTLmgnTWvE%3d https://na01.safelinks.protection.outlook.com/?url=206.127.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bXpqK3CMbzPQneUSTWRYicFcCPtt0E7CL7ygPqyCKiw%3d https://na01.safelinks.protection.outlook.com/?url=206.127.168.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j%2f%2bD56dffO3YPSivMfIS8HPzp2meJtJgPfsu%2bwskHgQ%3d Regards, Alfie _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QBThp6YCdJs%2bN%2bCaR3jN0tshnETATQXENrgU0xATtCM%3d Please contact info at arin.net if you experience any issues. From alfeh at me.com Sat Sep 12 19:25:59 2015 From: alfeh at me.com (Alfie Cleveland) Date: Sun, 13 Sep 2015 00:25:59 +0100 Subject: [arin-ppml] Unallocated IPs In-Reply-To: References: <69D81B64-4577-4D71-845C-275B7BE1C86F@me.com> Message-ID: <2F6C8375-413C-40CC-8AEF-39C93739E22E@me.com> Hey, I searched for some of these IPs but found no indication that some of them were ever allocated - nor allocated to any other RIR. ARIN indicates all inter-RIR transfers on the website. Regards, Alfie > On 13 Sep 2015, at 00:24, David Huberman wrote: > > They're probably either: > > In the returned, revoked, or held buckets (scheduled for reissue per arin's processes); or > > They don't belong to ARIN and are bits and pieces that belong to a different RIR > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf of Alfie Cleveland > Sent: Saturday, September 12, 2015 4:21:30 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Unallocated IPs > > Hey, > > I was doing some scanning of IP ranges and it appears that there are hundreds, if not thousands, of /21s and equivalents that are not assigned to anyone, yet do not appear on any ARIN inventory counters. Is this an oversight in the WHOIS or has ARIN 'forgotten' about these ranges? > > For reference, here are some of the blocks: > > https://na01.safelinks.protection.outlook.com/?url=206.53.141.0%2f23&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=b7GuMqK1CwA5vdJnij%2bBvoZPhqf5IPhTBFp4sKr%2fFb8%3d > https://na01.safelinks.protection.outlook.com/?url=206.53.168.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=C3Ubpm8P3KOF4aDZotwx0jOVcmqg%2fqC7dBt7Dn0EB4c%3d > https://na01.safelinks.protection.outlook.com/?url=206.53.200.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QyYU65jl%2f%2fntIdVMf%2f5AUtL7ALpxhoNSN0NEP8Yrz8c%3d > https://na01.safelinks.protection.outlook.com/?url=206.71.8.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CDMeW5wHGzMrmS2x%2fmxUqD%2bDPSDVqsL7nNbtpyD8vl4%3d > https://na01.safelinks.protection.outlook.com/?url=206.71.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=M0TR90y9HYivk36wrb8QN1XFNztKGD5Ecz%2bM9I%2bsRWY%3d > https://na01.safelinks.protection.outlook.com/?url=206.72.216.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mJ3e%2fwyRzHNUGxdueGtezBvx2OH7qiU2%2fgrQs8MIyP0%3d > https://na01.safelinks.protection.outlook.com/?url=206.80.232.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pd35AdjesrN6OMfmqojmC%2btr5G7ExF71qsNiB%2fQtoGE%3d > https://na01.safelinks.protection.outlook.com/?url=206.81.104.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=imEV3BdewVtbiOnYHdjWu2beDcGKzRIdK%2fYUwkyVqRs%3d > https://na01.safelinks.protection.outlook.com/?url=206.82.104.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ck6q0CAMoEqf%2bfNJ7ngLUl75g86lJROoQB6z%2bkf5ios%3d > https://na01.safelinks.protection.outlook.com/?url=206.83.8.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MG%2bUxFTi5kUoZAS%2blRnJUp2jH3fL5N8IKkSjIpHACgc%3d > https://na01.safelinks.protection.outlook.com/?url=206.83.40.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=S2EyD7tBXpbmB94vNlY6q%2bJctbSVmX7Mcavuzu6wc%2b4%3d > https://na01.safelinks.protection.outlook.com/?url=206.83.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uzQ81%2boxJhuEy1chzKIuDDwYNM0zAYQ7jDVt2jMK0w4%3d > https://na01.safelinks.protection.outlook.com/?url=206.124.40.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=soN9gJHRPHxND0U3M%2fWgmiPtIwP5s9BTqLTLmgnTWvE%3d > https://na01.safelinks.protection.outlook.com/?url=206.127.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bXpqK3CMbzPQneUSTWRYicFcCPtt0E7CL7ygPqyCKiw%3d > https://na01.safelinks.protection.outlook.com/?url=206.127.168.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j%2f%2bD56dffO3YPSivMfIS8HPzp2meJtJgPfsu%2bwskHgQ%3d > > Regards, > > Alfie > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QBThp6YCdJs%2bN%2bCaR3jN0tshnETATQXENrgU0xATtCM%3d > Please contact info at arin.net if you experience any issues. From bill at herrin.us Sat Sep 12 19:39:08 2015 From: bill at herrin.us (William Herrin) Date: Sat, 12 Sep 2015 19:39:08 -0400 Subject: [arin-ppml] Bot spamming via ppml posts In-Reply-To: References: Message-ID: On Sat, Sep 12, 2015 at 7:17 PM, William Herrin wrote: > On Sat, Sep 12, 2015 at 6:47 PM, Martin Hannigan wrote: >> Anyone else getting spam after posting? Since about 6 mos ago. Random. > > "Amy" with the half naked photo wants to go on a date with me every > time I post to PPML.Usually within minutes. Yep, there she is: Received: from server71.vfemail.pw (server71.vfemail.pw [107.170.172.192]) by magic.dirtside.com (8.14.3/) with ESMTP id t8CNV8k3031638 for ; Sat, 12 Sep 2015 19:31:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=getsmail.us; s=default; h=References:In-Reply-To:Content-Type:MIME-Version:To:Reply-To:From:Subject:Date:Message-ID; bh=nD0IKbuFB9Ex/Zj0YoFke7K8zFWkSBDRVAcKBjxAseo=; b=dJtOXtMvVw5pOL4FfQhGbpHxP2k20Fv+4Cq3X7cVsWQxt1zJ5Sf2quc6pAyxV2LOlEFHwEa+QD0jJ9FPz2gKyfMhMBQEbJ8dJFw4+klfzcnowUuTQSSlV/X/2HqnCNKIuPXvbitHETnVhJwTXBlV8sJv1GD8z0mUz4lva70fo8o=; Received: from [216.245.204.2] (port=59574 helo=vm1.getsmail.net) by server71.vfemail.pw with esmtpa (Exim 4.82) (envelope-from ) id 1ZauGA-0001gN-T2 for bill at herrin.us; Sat, 12 Sep 2015 19:31:07 -0400 Message-ID: <873d967cd0a2ee43cf42feec25e7142d5aadde63 at sm1.vbfssmail.com> Date: Sat, 12 Sep 2015 23:31:07 +0000 Subject: Re: [arin-ppml] Bot spamming via ppml posts From: AMY Reply-To: amy029 at getsmail.us To: William Herrin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=0e1195f5a77d3dcfe3f998dacd586173 In-Reply-To: References: -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From heather.skanks at gmail.com Sat Sep 12 19:48:03 2015 From: heather.skanks at gmail.com (Heather Schiller) Date: Sat, 12 Sep 2015 19:48:03 -0400 Subject: [arin-ppml] Unallocated IPs In-Reply-To: <2F6C8375-413C-40CC-8AEF-39C93739E22E@me.com> References: <69D81B64-4577-4D71-845C-275B7BE1C86F@me.com> <2F6C8375-413C-40CC-8AEF-39C93739E22E@me.com> Message-ID: <6C264FFC-91DF-406B-BBD4-89A3785DAF95@gmail.com> Do you have whowas access? Log in and look up the history of the block. --heather Sent from my iPhone > On Sep 12, 2015, at 7:25 PM, Alfie Cleveland wrote: > > Hey, > > I searched for some of these IPs but found no indication that some of them were ever allocated - nor allocated to any other RIR. ARIN indicates all inter-RIR transfers on the website. > > Regards, > Alfie > >> On 13 Sep 2015, at 00:24, David Huberman wrote: >> >> They're probably either: >> >> In the returned, revoked, or held buckets (scheduled for reissue per arin's processes); or >> >> They don't belong to ARIN and are bits and pieces that belong to a different RIR >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> >> ________________________________________ >> From: arin-ppml-bounces at arin.net on behalf of Alfie Cleveland >> Sent: Saturday, September 12, 2015 4:21:30 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Unallocated IPs >> >> Hey, >> >> I was doing some scanning of IP ranges and it appears that there are hundreds, if not thousands, of /21s and equivalents that are not assigned to anyone, yet do not appear on any ARIN inventory counters. Is this an oversight in the WHOIS or has ARIN 'forgotten' about these ranges? >> >> For reference, here are some of the blocks: >> >> https://na01.safelinks.protection.outlook.com/?url=206.53.141.0%2f23&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=b7GuMqK1CwA5vdJnij%2bBvoZPhqf5IPhTBFp4sKr%2fFb8%3d >> https://na01.safelinks.protection.outlook.com/?url=206.53.168.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=C3Ubpm8P3KOF4aDZotwx0jOVcmqg%2fqC7dBt7Dn0EB4c%3d >> https://na01.safelinks.protection.outlook.com/?url=206.53.200.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QyYU65jl%2f%2fntIdVMf%2f5AUtL7ALpxhoNSN0NEP8Yrz8c%3d >> https://na01.safelinks.protection.outlook.com/?url=206.71.8.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CDMeW5wHGzMrmS2x%2fmxUqD%2bDPSDVqsL7nNbtpyD8vl4%3d >> https://na01.safelinks.protection.outlook.com/?url=206.71.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=M0TR90y9HYivk36wrb8QN1XFNztKGD5Ecz%2bM9I%2bsRWY%3d >> https://na01.safelinks.protection.outlook.com/?url=206.72.216.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mJ3e%2fwyRzHNUGxdueGtezBvx2OH7qiU2%2fgrQs8MIyP0%3d >> https://na01.safelinks.protection.outlook.com/?url=206.80.232.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pd35AdjesrN6OMfmqojmC%2btr5G7ExF71qsNiB%2fQtoGE%3d >> https://na01.safelinks.protection.outlook.com/?url=206.81.104.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=imEV3BdewVtbiOnYHdjWu2beDcGKzRIdK%2fYUwkyVqRs%3d >> https://na01.safelinks.protection.outlook.com/?url=206.82.104.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ck6q0CAMoEqf%2bfNJ7ngLUl75g86lJROoQB6z%2bkf5ios%3d >> https://na01.safelinks.protection.outlook.com/?url=206.83.8.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MG%2bUxFTi5kUoZAS%2blRnJUp2jH3fL5N8IKkSjIpHACgc%3d >> https://na01.safelinks.protection.outlook.com/?url=206.83.40.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=S2EyD7tBXpbmB94vNlY6q%2bJctbSVmX7Mcavuzu6wc%2b4%3d >> https://na01.safelinks.protection.outlook.com/?url=206.83.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uzQ81%2boxJhuEy1chzKIuDDwYNM0zAYQ7jDVt2jMK0w4%3d >> https://na01.safelinks.protection.outlook.com/?url=206.124.40.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=soN9gJHRPHxND0U3M%2fWgmiPtIwP5s9BTqLTLmgnTWvE%3d >> https://na01.safelinks.protection.outlook.com/?url=206.127.136.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bXpqK3CMbzPQneUSTWRYicFcCPtt0E7CL7ygPqyCKiw%3d >> https://na01.safelinks.protection.outlook.com/?url=206.127.168.0%2f21&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j%2f%2bD56dffO3YPSivMfIS8HPzp2meJtJgPfsu%2bwskHgQ%3d >> >> Regards, >> >> Alfie >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c92458cace2fc49ff3f5508d2bbc8ef05%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QBThp6YCdJs%2bN%2bCaR3jN0tshnETATQXENrgU0xATtCM%3d >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From hannigan at gmail.com Sat Sep 12 19:49:11 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 12 Sep 2015 19:49:11 -0400 Subject: [arin-ppml] Bot spamming via ppml posts In-Reply-To: References: Message-ID: > On Sep 12, 2015, at 19:17, William Herrin wrote: > >> On Sat, Sep 12, 2015 at 6:47 PM, Martin Hannigan wrote: >> Anyone else getting spam after posting? Since about 6 mos ago. Random. > > "Amy" with the half naked photo wants to go on a date with me every > time I post to PPML.Usually within minutes. > > Yes. Thats her. "Amy". From scottleibrand at gmail.com Sat Sep 12 20:04:40 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sun, 13 Sep 2015 00:04:40 +0000 (UTC) Subject: [arin-ppml] Bot spamming via ppml posts In-Reply-To: References: Message-ID: DigitalOcean shut them down pretty quickly when I complained a few months ago. They haven't done so yet, though. We may need to re-escalate to the same person who handled it before.? -Scott _____________________________ From: William Herrin Sent: Saturday, September 12, 2015 4:39 PM Subject: Re: [arin-ppml] Bot spamming via ppml posts To: Martin Hannigan Cc: On Sat, Sep 12, 2015 at 7:17 PM, William Herrin wrote: > On Sat, Sep 12, 2015 at 6:47 PM, Martin Hannigan wrote: >> Anyone else getting spam after posting? Since about 6 mos ago. Random. > > "Amy" with the half naked photo wants to go on a date with me every > time I post to PPML.Usually within minutes. Yep, there she is: Received: from server71.vfemail.pw (server71.vfemail.pw [107.170.172.192]) by magic.dirtside.com (8.14.3/) with ESMTP id t8CNV8k3031638 for ; Sat, 12 Sep 2015 19:31:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=getsmail.us; s=default; h=References:In-Reply-To:Content-Type:MIME-Version:To:Reply-To:From:Subject:Date:Message-ID; bh=nD0IKbuFB9Ex/Zj0YoFke7K8zFWkSBDRVAcKBjxAseo=; b=dJtOXtMvVw5pOL4FfQhGbpHxP2k20Fv+4Cq3X7cVsWQxt1zJ5Sf2quc6pAyxV2LOlEFHwEa+QD0jJ9FPz2gKyfMhMBQEbJ8dJFw4+klfzcnowUuTQSSlV/X/2HqnCNKIuPXvbitHETnVhJwTXBlV8sJv1GD8z0mUz4lva70fo8o=; Received: from [216.245.204.2] (port=59574 helo=vm1.getsmail.net) by server71.vfemail.pw with esmtpa (Exim 4.82) (envelope-from ) id 1ZauGA-0001gN-T2 for bill at herrin.us; Sat, 12 Sep 2015 19:31:07 -0400 Message-ID: <873d967cd0a2ee43cf42feec25e7142d5aadde63 at sm1.vbfssmail.com> Date: Sat, 12 Sep 2015 23:31:07 +0000 Subject: Re: [arin-ppml] Bot spamming via ppml posts From: AMY Reply-To: amy029 at getsmail.us To: William Herrin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=0e1195f5a77d3dcfe3f998dacd586173 In-Reply-To: References: -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Sep 13 00:41:53 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 12 Sep 2015 21:41:53 -0700 Subject: [arin-ppml] Bot spamming via ppml posts In-Reply-To: References: Message-ID: Yes... The problem GS been reported to ARIN staff and they are trying to resolve it. Unfortunately, since the person behind this is apparently sending the spam outside of the mailing list only using a subscription to harvest poster's addresses, it is difficult to identify the culprit. Owen > On Sep 12, 2015, at 15:47, Martin Hannigan wrote: > > > Anyone else getting spam after posting? Since about 6 mos ago. Random. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Sep 15 15:14:26 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Sep 2015 12:14:26 -0700 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) Message-ID: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Speaking strictly as myself and not in any way on behalf of the AC or anyone else: There has been significant misunderstanding around this policy proposal. Much of the opposition seems to center around the idea that this proposal would somehow reduce permitted out of region use. In fact, it restricts staff?s ability to disregard out-of-region use as invalid and it expands the ability of organizations to utilize ARIN resources globally. While I would like to have seen a simpler proposal that addressed this problem more directly, the simple reality is that a combination of legal concerns and other factors have necessitated the level of complexity in this proposal. I support the proposal as written. I encourage others that would like to see their out-of-region use counted as valid utilization when applying for additional resources via transfer or other mechanism to also express their support for this proposal as it is currently written. Even if you have previously expressed support for this proposal, since it was recently updated with (hopefully improved) language that should be easier to understand, it is helpful to the AC if you express your continued support. Of course, as an AC member, I will say that all feedback, positive or negative on this proposal is useful. It certainly isn?t my intent to discourage those who oppose this proposal as written from speaking. Owen From bill at herrin.us Tue Sep 15 15:50:32 2015 From: bill at herrin.us (William Herrin) Date: Tue, 15 Sep 2015 15:50:32 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Tue, Sep 15, 2015 at 3:14 PM, Owen DeLong wrote: > There has been significant misunderstanding around this policy proposal. This proposal is a turkey, Owen. It doesn't do an adequate job of what any of us want it to do, whether for or against out-of-region use. It should be abandoned. If further work on out-of-region use policy is desired, consider pursuing a globally coordinated proposal that would facilitate global use in a fair and expansive manner. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From scottleibrand at gmail.com Tue Sep 15 16:19:06 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 15 Sep 2015 13:19:06 -0700 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: Does anyone actually think globally coordinated policy on this topic will go anywhere? Seems like a dead end to me. If you're concerned about the complexity of 2015-5, there is also ARIN-2015-6: Transfers and Multi-national Networks, which while only addressing a subset of the problem may be "good enough"... -Scott On Tue, Sep 15, 2015 at 12:50 PM, William Herrin wrote: > On Tue, Sep 15, 2015 at 3:14 PM, Owen DeLong wrote: > > There has been significant misunderstanding around this policy proposal. > > This proposal is a turkey, Owen. It doesn't do an adequate job of what > any of us want it to do, whether for or against out-of-region use. > > It should be abandoned. If further work on out-of-region use policy is > desired, consider pursuing a globally coordinated proposal that would > facilitate global use in a fair and expansive manner. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 matthew at matthew.at Tue Sep 15 16:19:25 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 15 Sep 2015 13:19:25 -0700 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: <55F87D4D.8020700@matthew.at> On 9/15/2015 12:50 PM, William Herrin wrote: > On Tue, Sep 15, 2015 at 3:14 PM, Owen DeLong wrote: >> There has been significant misunderstanding around this policy proposal. > This proposal is a turkey, Owen. It doesn't do an adequate job of what > any of us want it to do, whether for or against out-of-region use. > > It should be abandoned. If further work on out-of-region use policy is > desired, consider pursuing a globally coordinated proposal that would > facilitate global use in a fair and expansive manner. > It might be a turkey, but the real problem is that RIRs decided, on their own, that the Internet wasn't global in nature. Why do we need globally coordinated policy to acknowledge something that was true long before they came into being? There has never, ever, been a technical reason why I couldn't use IPv4 addresses allocated to me anywhere I wanted, including in space. Matthew Kaufman From David.Huberman at microsoft.com Tue Sep 15 16:36:08 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 15 Sep 2015 20:36:08 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: Bill, Ignoring what 2015-5 says and how it's constructed, what is your opinion of the fundamental issue here? Do you think network operators should be allowed to take ARIN-issued resources and use them anywhere in the world, regardless of topology? In answering this, please understand that ARIN's current procedure is "NO". Thanks /david David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Tuesday, September 15, 2015 12:51 PM > To: Owen DeLong > Cc: ARIN PPML (ppml at arin.net) > Subject: Re: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region > use of IPv4 space) > > On Tue, Sep 15, 2015 at 3:14 PM, Owen DeLong wrote: > > There has been significant misunderstanding around this policy proposal. > > This proposal is a turkey, Owen. It doesn't do an adequate job of what any of > us want it to do, whether for or against out-of-region use. > > It should be abandoned. If further work on out-of-region use policy is > desired, consider pursuing a globally coordinated proposal that would > facilitate global use in a fair and expansive manner. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, > Dirtside Systems ......... Web: > irtside.com%2f&data=01%7c01%7cdavid.huberman%40microsoft.com%7c42 > 7a0eabde744a25da1308d2be0903f1%7c72f988bf86f141af91ab2d7cd011db47 > %7c1&sdata=3SI7NBE%2fYLJwQj5Ll92fXvcC%2f4e8uqZB5JBBGU7YCnQ%3d> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin > .net%2fmailman%2flistinfo%2farin- > ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c427a0eabde > 744a25da1308d2be0903f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat > a=3tDKAO19r8hGNwD5JIRcgJqxEU%2bCe2s8WXs0U8otBac%3d > Please contact info at arin.net if you experience any issues. From hannigan at gmail.com Tue Sep 15 16:42:21 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 15 Sep 2015 21:42:21 +0100 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> > On Sep 15, 2015, at 21:36, David Huberman wrote: > > Bill, > > Ignoring what 2015-5 says and how it's constructed, what is your opinion of the fundamental issue here? Do you think network operators should be allowed to take ARIN-issued resources and use them anywhere in the world, regardless of topology? In answering this, please understand that ARIN's current procedure is "NO". > Thats inaccurate. The answer has recently been yes. At least for some. Feel free to un confuse me. I'd appreciate it. Best, -M< From bill at herrin.us Tue Sep 15 16:45:05 2015 From: bill at herrin.us (William Herrin) Date: Tue, 15 Sep 2015 16:45:05 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Tue, Sep 15, 2015 at 4:19 PM, Scott Leibrand wrote: > Does anyone actually think globally coordinated policy on this topic will go > anywhere? Not the first attempt, no. But if you're serious about re-globalizing address space management after InterNIC was taken apart two decades ago, that's the place to start working the problem. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From David.Huberman at microsoft.com Tue Sep 15 17:02:55 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 15 Sep 2015 21:02:55 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> Message-ID: Hi Marty, 1) In 2010/2011, ARIN started seeing applications for IPv4 addresses from out of the region. 2) The staff prepared a report which Leslie presented at a Public Policy Meeting, and a draft policy proposal was prepared and presented to the community at the 2011 ARIN meeting in Philadelphia. As a result of the consensus of the room at that meeting, and as a result of further community feedback over the years, ARIN implemented policy thusly: ALL OUT-OF-REGION USE which is not tied to a route announcement originating from a router in the ARIN region is not counted when staff measure utilization towards obtaining additional assignments from ARIN. To be clear: -I have a /20. - I want to transfer in more space via 8.3. - To qualify for an 8.3 transfer, I have to be 80%+ utilized on my /20. - I announce and use a /21 in Chicago - I announce and use a /21 in Hong Kong - I am 100% utilized. - I have no backbone, and no other route announcements are present. ARIN will deny the request to transfer in more space. They count me at 50% utilized because the Hong Kong space is used out of region, with no cover route anchored from equipment in the ARIN region. 3) This explains why ARIN has a standard question to every request: "In accordance with section 2.2 of the NRPM, ARIN issues number resources for use within its region. Please confirm the requested number resources will be routed within the ARIN region." Does that un-confuse you? I believe ARIN should no longer take topology into account. ARIN had good reasons to do so formerly, but with exhaustion now reached, I think those reasons are moot. David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Martin Hannigan [mailto:hannigan at gmail.com] > Sent: Tuesday, September 15, 2015 1:42 PM > To: ARIN PPML (ppml at arin.net) ; David Huberman > > Subject: Re: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region > use of IPv4 space) > > > > > > > On Sep 15, 2015, at 21:36, David Huberman > wrote: > > > > Bill, > > > > Ignoring what 2015-5 says and how it's constructed, what is your opinion of > the fundamental issue here? Do you think network operators should be > allowed to take ARIN-issued resources and use them anywhere in the world, > regardless of topology? In answering this, please understand that ARIN's > current procedure is "NO". > > > > > Thats inaccurate. The answer has recently been yes. At least for some. > > Feel free to un confuse me. I'd appreciate it. > > Best, > > -M< From bill at herrin.us Tue Sep 15 17:24:48 2015 From: bill at herrin.us (William Herrin) Date: Tue, 15 Sep 2015 17:24:48 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Tue, Sep 15, 2015 at 4:36 PM, David Huberman wrote: > Ignoring what 2015-5 says and how it's constructed, what is > your opinion of the fundamental issue here? Do you think > network operators should be allowed to take ARIN-issued > resources and use them anywhere in the world, regardless > of topology? In answering this, please understand that > ARIN's current procedure is "NO". Hi David, I think that's the wrong question. I think that's a destructive question with answers that range from bad to worse. A better question is: should we have regionally confined resource pools (and policies) or global resource pools (and policies)? There was a proposition posted here a while back to the effect that the regional registries were only supposed to be a local interface to the global address system. They weren't supposed to diverge in to distinct governance regimes. Would that be better? There is extra challenge in developing global policy, but it would in theory permit the assignments to be used globally without creating any "flag of convenience" fairness problems. But... is permission to employ addresses globally worth the cost of regional autonomy? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From David.Huberman at microsoft.com Tue Sep 15 17:34:45 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 15 Sep 2015 21:34:45 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: Hi Bill, I agree with what you've written and its implications. The time for RIRs being anything other than local language/time/etc is passed, in my humble opinion. But here's the problem: I do not believe LACNIC would agree with such a policy. Right now they're debating allowing an inter-RIR transfer policy that ONLY allows inbound transfers; it disallows space from leaving the region. A two-way policy is a non-starter. (And the one-way policy is facing stiff opposition.) So if you believe me - if you believe a global policy cannot be passed right now because at least one RIR won't agree to it - what do we do here in the ARIN region, where ARIN staff are applying policy in a way which restricts use? Staff have told us they need a policy change to do anything. Thanks /david David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Tuesday, September 15, 2015 2:25 PM > To: David Huberman > Cc: ARIN PPML (ppml at arin.net) > Subject: Re: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region > use of IPv4 space) > > On Tue, Sep 15, 2015 at 4:36 PM, David Huberman > wrote: > > Ignoring what 2015-5 says and how it's constructed, what is your > > opinion of the fundamental issue here? Do you think network operators > > should be allowed to take ARIN-issued resources and use them anywhere > > in the world, regardless > > of topology? In answering this, please understand that > > ARIN's current procedure is "NO". > > > Hi David, > > I think that's the wrong question. I think that's a destructive question with > answers that range from bad to worse. > > A better question is: should we have regionally confined resource pools (and > policies) or global resource pools (and policies)? > > There was a proposition posted here a while back to the effect that the > regional registries were only supposed to be a local interface to the global > address system. They weren't supposed to diverge in to distinct governance > regimes. Would that be better? > > There is extra challenge in developing global policy, but it would in theory > permit the assignments to be used globally without creating any "flag of > convenience" fairness problems. But... is permission to employ addresses > globally worth the cost of regional autonomy? > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, > Dirtside Systems ......... Web: > irtside.com%2f&data=01%7c01%7cDavid.Huberman%40microsoft.com%7cec > 5008008600445cd90308d2be142561%7c72f988bf86f141af91ab2d7cd011db47% > 7c1&sdata=ZKlYit9LM2K5w93SX5skcz9w3RUdtv8WePJU1YJztMA%3d> From matthew at matthew.at Tue Sep 15 17:44:26 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 15 Sep 2015 14:44:26 -0700 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: <55F8913A.1050403@matthew.at> Isn't the easier answer to just buy IP address space from others and not bother registering the purchase with ARIN? Then you don't need to meet *any* of the policies that impact transfers. Matthew Kaufman From jcurran at arin.net Tue Sep 15 17:48:24 2015 From: jcurran at arin.net (John Curran) Date: Tue, 15 Sep 2015 21:48:24 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> Message-ID: On Sep 15, 2015, at 4:42 PM, Martin Hannigan wrote: >> On Sep 15, 2015, at 21:36, David Huberman wrote: >> >> Bill, >> >> Ignoring what 2015-5 says and how it's constructed, what is your opinion of the fundamental issue here? Do you think network operators should be allowed to take ARIN-issued resources and use them anywhere in the world, regardless of topology? In answering this, please understand that ARIN's current procedure is "NO". > > Thats inaccurate. The answer has recently been yes. At least for some. > > Feel free to un confuse me. I'd appreciate it. ?Use? of number resources is entirely up to the recipient; i.e. ARIN cannot/does not control how parties route number resources issued to them. However, how you route your number resources can indeed impact the processing of _future_ requests. In general, ARIN does not consider out-of-region use of number resources as part of overall utilization, except where there's a covering route from equipment in the region. Thanks, /John John Curran President and CEO ARIN From aaron at wholesaleinternet.net Tue Sep 15 17:49:58 2015 From: aaron at wholesaleinternet.net (Aaron) Date: Tue, 15 Sep 2015 16:49:58 -0500 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <55F8913A.1050403@matthew.at> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> Message-ID: <55F89286.2090502@wholesaleinternet.net> Nope. A few years ago we purchased some IP space from a company that was downsizing. We never got around to registering the IPs with ARIN and a year later the seller was back, reclaimed them, sold them to someone else and disappeared. Nothing we could do about it without proper registration. Aaron On 9/15/2015 4:44 PM, Matthew Kaufman wrote: > Isn't the easier answer to just buy IP address space from others and > not bother registering the purchase with ARIN? Then you don't need to > meet *any* of the policies that impact transfers. > > Matthew Kaufman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From matthew at matthew.at Tue Sep 15 17:50:12 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 15 Sep 2015 14:50:12 -0700 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> Message-ID: <55F89294.7080403@matthew.at> On 9/15/2015 2:48 PM, John Curran wrote: > On Sep 15, 2015, at 4:42 PM, Martin Hannigan wrote: >>> On Sep 15, 2015, at 21:36, David Huberman wrote: >>> >>> Bill, >>> >>> Ignoring what 2015-5 says and how it's constructed, what is your opinion of the fundamental issue here? Do you think network operators should be allowed to take ARIN-issued resources and use them anywhere in the world, regardless of topology? In answering this, please understand that ARIN's current procedure is "NO". >> Thats inaccurate. The answer has recently been yes. At least for some. >> >> Feel free to un confuse me. I'd appreciate it. > > ?Use? of number resources is entirely up to the recipient; i.e. ARIN cannot/does not control > how parties route number resources issued to them. > > However, how you route your number resources can indeed impact the processing of > _future_ requests. In general, ARIN does not consider out-of-region use of number > resources as part of overall utilization, except where there's a covering route from > equipment in the region. > Makes me want to announce 128.0.0.0/1 - "just to be sure" Matthew Kaufman From jcurran at arin.net Tue Sep 15 17:51:19 2015 From: jcurran at arin.net (John Curran) Date: Tue, 15 Sep 2015 21:51:19 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <55F8913A.1050403@matthew.at> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> Message-ID: > On Sep 15, 2015, at 5:44 PM, Matthew Kaufman wrote: > > Isn't the easier answer to just buy IP address space from others and not bother registering the purchase with ARIN? Then you don't need to meet *any* of the policies that impact transfers. Indeterminate, since It?s unclear what you might be obtaining the rights to, if not actual rights to the entry in the Internet Number Registry System. Such rights to the address block actually transfer only after the request has been completed at the registry. /John John Curran President and CEO ARIN From matthew at matthew.at Tue Sep 15 17:55:03 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 15 Sep 2015 14:55:03 -0700 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <55F89286.2090502@wholesaleinternet.net> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> <55F89286.2090502@wholesaleinternet.net> Message-ID: <55F893B7.5010002@matthew.at> On 9/15/2015 2:49 PM, Aaron wrote: > Nope. > > A few years ago we purchased some IP space from a company that was > downsizing. We never got around to registering the IPs with ARIN and > a year later the seller was back, reclaimed them, sold them to someone > else and disappeared. > > Nothing we could do about it without proper registration. If you had an actual contract from them, there's a lot more than "nothing" you can do. See your attorney. Matthew Kaufman From matthew at matthew.at Tue Sep 15 17:57:15 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 15 Sep 2015 14:57:15 -0700 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> Message-ID: <55F8943B.1060306@matthew.at> On 9/15/2015 2:51 PM, John Curran wrote: >> On Sep 15, 2015, at 5:44 PM, Matthew Kaufman wrote: >> >> Isn't the easier answer to just buy IP address space from others and not bother registering the purchase with ARIN? Then you don't need to meet *any* of the policies that impact transfers. > Indeterminate, since It?s unclear what you might be obtaining the rights to, > if not actual rights to the entry in the Internet Number Registry System. Sure it is. I'd be obtaining the rights to whatever was specified in the purchase contract and/or listed on the bill of sale. The "rights to the entry in the Internet Number Registry System" are provably not necessary in order to make use of the space. > Such > rights to the address block actually transfer only after the request has been > completed at the registry. Yes, we've heard this before. All ARIN does is maintain the records, and all you are transferring is the entry in the database. Got it. Doesn't impact routing tables or the exchange of money. That's why leasing is possible, buying outside of the registration is possible, rights of first refusal are possible, etc. Matthew Kaufman From aaron at wholesaleinternet.net Tue Sep 15 18:03:23 2015 From: aaron at wholesaleinternet.net (Aaron) Date: Tue, 15 Sep 2015 17:03:23 -0500 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <55F893B7.5010002@matthew.at> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> <55F89286.2090502@wholesaleinternet.net> <55F893B7.5010002@matthew.at> Message-ID: <55F895AB.6080301@wholesaleinternet.net> We found it difficult to sue a company that vanished. On 9/15/2015 4:55 PM, Matthew Kaufman wrote: > On 9/15/2015 2:49 PM, Aaron wrote: >> Nope. >> >> A few years ago we purchased some IP space from a company that was >> downsizing. We never got around to registering the IPs with ARIN and >> a year later the seller was back, reclaimed them, sold them to >> someone else and disappeared. >> >> Nothing we could do about it without proper registration. > > If you had an actual contract from them, there's a lot more than > "nothing" you can do. See your attorney. > > Matthew Kaufman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From jcurran at arin.net Tue Sep 15 18:03:38 2015 From: jcurran at arin.net (John Curran) Date: Tue, 15 Sep 2015 22:03:38 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <55F893B7.5010002@matthew.at> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> <55F89286.2090502@wholesaleinternet.net> <55F893B7.5010002@matthew.at> Message-ID: <63B4347E-CC28-434A-8366-D2773B5B7B0E@corp.arin.net> > On Sep 15, 2015, at 5:55 PM, Matthew Kaufman wrote: > > On 9/15/2015 2:49 PM, Aaron wrote: >> Nope. >> >> A few years ago we purchased some IP space from a company that was downsizing. We never got around to registering the IPs with ARIN and a year later the seller was back, reclaimed them, sold them to someone else and disappeared. >> >> Nothing we could do about it without proper registration. > > If you had an actual contract from them, there's a lot more than "nothing" you can do. See your attorney. The contents of the contract are also likely to be be germane to the situation; I?ve heard people describe address blocks described as ?the right to route IP addresses nnn-mmm in the global routing table?, which needless to say, does not actually exist and thus can?t be conveyed. /John John Curran President and CEO ARIN From hannigan at gmail.com Tue Sep 15 18:19:28 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 15 Sep 2015 23:19:28 +0100 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <55F8943B.1060306@matthew.at> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> <55F8943B.1060306@matthew.at> Message-ID: On Tue, Sep 15, 2015 at 10:57 PM, Matthew Kaufman wrote: > On 9/15/2015 2:51 PM, John Curran wrote: > >> On Sep 15, 2015, at 5:44 PM, Matthew Kaufman wrote: >>> >>> Isn't the easier answer to just buy IP address space from others and not >>> bother registering the purchase with ARIN? Then you don't need to meet >>> *any* of the policies that impact transfers. >>> >> Indeterminate, since It?s unclear what you might be obtaining the rights >> to, >> if not actual rights to the entry in the Internet Number Registry System. >> > > Sure it is. I'd be obtaining the rights to whatever was specified in the > purchase contract and/or listed on the bill of sale. > > The "rights to the entry in the Internet Number Registry System" are > provably not necessary in order to make use of the space. > > Such >> rights to the address block actually transfer only after the request has >> been >> completed at the registry. >> > > Yes, we've heard this before. All ARIN does is maintain the records, and > all you are transferring is the entry in the database. Got it. Doesn't > impact routing tables or the exchange of money. > > That's why leasing is possible, buying outside of the registration is > possible, rights of first refusal are possible, etc. > This is all not only possible, but in practice. ARIN has known that this has been happening for many years now. See slide 7 http://bit.ly/1ifoSAV for at least the start of the conversation. There's a great pub tale around how this story developed. See me in Montreal. :) The best way to fix this is to truly focus on the registry and follow the lead of the other regions. YMMV, Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Sep 15 18:25:13 2015 From: jcurran at arin.net (John Curran) Date: Tue, 15 Sep 2015 22:25:13 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <55F8943B.1060306@matthew.at> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> <55F8943B.1060306@matthew.at> Message-ID: <1C299CA4-60BD-43C5-A2D1-04F6F728EDBF@arin.net> On Sep 15, 2015, at 5:57 PM, Matthew Kaufman wrote: > > On 9/15/2015 2:51 PM, John Curran wrote: >>> On Sep 15, 2015, at 5:44 PM, Matthew Kaufman wrote: >>> >>> Isn't the easier answer to just buy IP address space from others and not bother registering the purchase with ARIN? Then you don't need to meet *any* of the policies that impact transfers. >> Indeterminate, since It?s unclear what you might be obtaining the rights to, >> if not actual rights to the entry in the Internet Number Registry System. > > Sure it is. I'd be obtaining the rights to whatever was specified in the purchase contract and/or listed on the bill of sale. Indeed, hence the need for a clear description of what rights are being obtained to what object. > The "rights to the entry in the Internet Number Registry System" are provably not necessary in order to make use of the space. Quite correct. e.g. cybersquatters routinely use space to which they have no rights. Some service providers check to see if the address holder is agreeing to routing of an address block, and some do not. Some accept letters of agency, with various degrees of assurance, and some do not, etc. /John John Curran President and CEO ARIN From bill at herrin.us Tue Sep 15 18:29:12 2015 From: bill at herrin.us (William Herrin) Date: Tue, 15 Sep 2015 18:29:12 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Tue, Sep 15, 2015 at 5:34 PM, David Huberman wrote: > I agree with what you've written and its implications. The time for > RIRs being anything other than local language/time/etc is passed, > in my humble opinion. > > But here's the problem: I do not believe LACNIC would agree with > such a policy. Right now they're debating allowing an inter-RIR transfer > policy that ONLY allows inbound transfers; it disallows space from > leaving the region. A two-way policy is a non-starter. (And the > one-way policy is facing stiff opposition.) Hi David, In that case, folks operating portions of their network in the LACNIC region should follow LACNIC's policies with LACNIC's resources. Asking ARIN for permission to do an end-run around LACNIC is so blatantly unfair that it doesn't merit serious discussion. What can we do that leads in a more positive direction? That's a harder question. Policies in the past have either been purely regional or purely global. I don't suppose that really has to be true in the future. Two or three RIRs could consent to merged policies with resources to be validly used throughout all of the participating regions. If that's a helpful destination, the discussion can be kick-started with a draft globally coordinated policy. The first draft will surely fail... but it'll start the discussion in every region. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jcurran at arin.net Tue Sep 15 18:35:43 2015 From: jcurran at arin.net (John Curran) Date: Tue, 15 Sep 2015 22:35:43 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <55F8913A.1050403@matthew.at> <55F8943B.1060306@matthew.at> Message-ID: On Sep 15, 2015, at 6:19 PM, Martin Hannigan > wrote: This is all not only possible, but in practice. ARIN has known that this has been happening for many years now. See slide 7 http://bit.ly/1ifoSAV for at least the start of the conversation. There's a great pub tale around how this story developed. See me in Montreal. :) Correct - such use of address space works because overall the ISP community appears to want it to. i.e. there is no need for ARIN (or any other RIR) to take any action unless the community determines otherwise and specifies actual policy in this area. If folks want it to work otherwise, then they know how to develop policy accordingly. See my email to this list from 2012 on this topic... /John John Curran President and CEO ARIN === Begin forwarded message: From: John Curran > Subject: [arin-ppml] Leasing (was: Re: IPv4 Update) Date: August 22, 2012 9:18:33 PM EDT To: Enrique Garcia > Cc: "arin-ppml at arin.net" > On Aug 22, 2012, at 9:58 AM, Enrique Garcia > wrote: I received an e-mail this morning from a company claiming that IP Space can now be leased. Was just wondering if this was legal. Enrique - If by "legal", you mean "in compliance with the community number resource management policy in this region", then perhaps I can provide some insight. Internet service providers routinely provide IP address assignments as part of their Internet services bundle, and those assignments are not permanent in nature but only for the duration of the service agreement. Many would consider such assignments to be "leased IP address space". Organizations receiving IP address space (as the recipient of a transfer or via allocations of IP address space from the free pool) as an ISP must meet the LIR definition (per NRPM 2.4) and that means "primarily assigning address space to the users of the network services that it provides." End-users receiving transfers or assignments of IP address space from the free pool must meet the End-user definition (per NRPM 2.6) during their request which requires they be receiving space to be used "exclusively for use in its operational networks." Ergo, the "leasing" of recently received space could reasonably raise concern about whether the request to ARIN for that space was made with full sincerity, and organizations would be advised not to request to receive IP address from the free pool or as the recipient of a transfer if their intent is to "lease" the space rather then use it for their network service customers (if an ISP) or use it for their own network (if they applied as an end-user.) There has been no policy development specifically regarding leasing as an appropriate/inappropriate use of held IP address space, so ARIN does not have a position either way (aside from the case above of insuring that requests to receive additional address space are made in good faith based on existing definitions of usage.) Obviously, individual Internet service providers may have their own views on handling of "leased" address space, depending on any number of factors including registrant and block size. I hope this helps somewhat in understanding the situation, recognizing that it is not likely to be as complete an answer as you would have liked. Thanks! /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Tue Sep 15 19:54:09 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 16 Sep 2015 00:54:09 +0100 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> Message-ID: On Tue, Sep 15, 2015 at 10:02 PM, David Huberman < David.Huberman at microsoft.com> wrote: > Hi Marty, > > 1) In 2010/2011, ARIN started seeing applications for IPv4 addresses from > out of the region. > > 2) The staff prepared a report which Leslie presented at a Public Policy > Meeting, and a draft policy proposal was prepared and presented to the > community at the 2011 ARIN meeting in Philadelphia. As a result of the > consensus of the room at that meeting, and as a result of further community > feedback over the years, ARIN implemented policy thusly: > ALL OUT-OF-REGION USE which is not tied to a route announcement originating > from a router in the ARIN region is not counted when staff measure > utilization towards obtaining additional assignments from ARIN. > > To be clear: > -I have a /20. > - I want to transfer in more space via 8.3. > - To qualify for an 8.3 transfer, I have to be 80%+ utilized on my /20. > - I announce and use a /21 in Chicago > - I announce and use a /21 in Hong Kong > - I am 100% utilized. > - I have no backbone, and no other route announcements are present. > > ARIN will deny the request to transfer in more space. They count me at > 50% utilized because the Hong Kong space is used out of region, with no > cover route anchored from equipment in the ARIN region. > > 3) This explains why ARIN has a standard question to every request: > > "In accordance with section 2.2 of the NRPM, ARIN issues number resources > for use within its region. Please confirm the requested number resources > will be routed within the ARIN region." > > Does that un-confuse you? I believe ARIN should no longer take topology > into account. ARIN had good reasons to do so formerly, but with exhaustion > now reached, I think those reasons are moot. > Why do we need a policy to undo something that was never a policy in the first place? What was made up on the fly should be able to undone in the same manner, especially considering how egregious this proposal is. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Sep 15 20:19:58 2015 From: bill at herrin.us (William Herrin) Date: Tue, 15 Sep 2015 20:19:58 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> Message-ID: On Tue, Sep 15, 2015 at 7:54 PM, Martin Hannigan wrote: > Why do we need a policy to undo something that was never a policy in the > first place? What was made up on the fly should be able to undone in the > same manner, especially considering how egregious this proposal is. Hi Marty, Weak enforcement is not lack of a policy. NRPM 2.2 and functionally identical language have been on the books all the way back to ARIN's formation. There has been a tacit understanding that minor outregion use would not be significantly penalized. On a practical level, outregion use minor enough to disappear in to the rest of your allocation still isn't penalized. You're caught because you made wholesale use (not minor use) of ARIN addresses outregion and with pool depletion ARIN is asking tougher compliance questions. David says, "the time for RIRs being anything other than local language/time/etc is passed." If you agree, global policy changes will be needed to make it happen. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jlewis at lewis.org Tue Sep 15 20:56:26 2015 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 15 Sep 2015 20:56:26 -0400 (EDT) Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: Are we to wait for a new RIR to incorporate to service the moon if someone wants to put an IPv4 network on the moon thats reachable from earth's IPv4 Internet? It's out of every RIR's region. "Sorry, you can't take our IPs there." On Tue, 15 Sep 2015, David Huberman wrote: > Bill, > > Ignoring what 2015-5 says and how it's constructed, what is your opinion of the fundamental issue here? Do you think network operators should be allowed to take ARIN-issued resources and use them anywhere in the world, regardless of topology? In answering this, please understand that ARIN's current procedure is "NO". > > Thanks > /david > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of William Herrin >> Sent: Tuesday, September 15, 2015 12:51 PM >> To: Owen DeLong >> Cc: ARIN PPML (ppml at arin.net) >> Subject: Re: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region >> use of IPv4 space) >> >> On Tue, Sep 15, 2015 at 3:14 PM, Owen DeLong wrote: >>> There has been significant misunderstanding around this policy proposal. >> >> This proposal is a turkey, Owen. It doesn't do an adequate job of what any of >> us want it to do, whether for or against out-of-region use. >> >> It should be abandoned. If further work on out-of-region use policy is >> desired, consider pursuing a globally coordinated proposal that would >> facilitate global use in a fair and expansive manner. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, >> Dirtside Systems ......... Web: >> > irtside.com%2f&data=01%7c01%7cdavid.huberman%40microsoft.com%7c42 >> 7a0eabde744a25da1308d2be0903f1%7c72f988bf86f141af91ab2d7cd011db47 >> %7c1&sdata=3SI7NBE%2fYLJwQj5Ll92fXvcC%2f4e8uqZB5JBBGU7YCnQ%3d> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin >> .net%2fmailman%2flistinfo%2farin- >> ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c427a0eabde >> 744a25da1308d2be0903f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat >> a=3tDKAO19r8hGNwD5JIRcgJqxEU%2bCe2s8WXs0U8otBac%3d >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcurran at arin.net Tue Sep 15 21:27:18 2015 From: jcurran at arin.net (John Curran) Date: Wed, 16 Sep 2015 01:27:18 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: <705737A3-8535-40DE-AA32-D1986A4E1413@corp.arin.net> On Sep 15, 2015, at 8:56 PM, Jon Lewis wrote: > > Are we to wait for a new RIR to incorporate to service the moon if someone wants to put an IPv4 network on the moon thats reachable from earth's IPv4 Internet? It's out of every RIR's region. "Sorry, you can't take our IPs there.? As noted in my reply to David earlier, use of number resources is entirely up to the recipient; ARIN cannot/does not control how or where parties route number resources issued to them. Use of number resources outside the region can impact future requests to receive address space either from ARIN?s free pool or via transfer (although the former will shortly become a moot point.) /John John Curran President and CEO ARIN From bill at herrin.us Tue Sep 15 21:37:06 2015 From: bill at herrin.us (William Herrin) Date: Tue, 15 Sep 2015 21:37:06 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Tue, Sep 15, 2015 at 8:56 PM, Jon Lewis wrote: > Are we to wait for a new RIR to incorporate to service the moon if someone > wants to put an IPv4 network on the moon thats reachable from earth's IPv4 > Internet? It's out of every RIR's region. "Sorry, you can't take our IPs > there." Hi Jon, All space vehicles (and airplanes and ships) are in one or another terrestrial country's legal jurisdiction. Your moon base would fly the flag of a country in one of the RIR's jurisdictions. Should science fiction slide towards science reality and we start having nations on the moon, mars and in the asteroid belt, AFAIK ARIN is still the default registry for nations not claimed by another RIR. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jlewis at lewis.org Wed Sep 16 01:27:27 2015 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 16 Sep 2015 01:27:27 -0400 (EDT) Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Tue, 15 Sep 2015, William Herrin wrote: > On Tue, Sep 15, 2015 at 8:56 PM, Jon Lewis wrote: >> Are we to wait for a new RIR to incorporate to service the moon if someone >> wants to put an IPv4 network on the moon thats reachable from earth's IPv4 >> Internet? It's out of every RIR's region. "Sorry, you can't take our IPs >> there." > > Hi Jon, > > All space vehicles (and airplanes and ships) are in one or another > terrestrial country's legal jurisdiction. Your moon base would fly the > flag of a country in one of the RIR's jurisdictions. > > Should science fiction slide towards science reality and we start > having nations on the moon, mars and in the asteroid belt, AFAIK ARIN > is still the default registry for nations not claimed by another RIR. So can we get an exception to this rule if we put a US flag sticker on our out of region routers? :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bill at herrin.us Wed Sep 16 09:51:46 2015 From: bill at herrin.us (William Herrin) Date: Wed, 16 Sep 2015 09:51:46 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Wed, Sep 16, 2015 at 1:27 AM, Jon Lewis wrote: > On Tue, 15 Sep 2015, William Herrin wrote: >> All space vehicles (and airplanes and ships) are in one or another >> terrestrial country's legal jurisdiction. Your moon base would fly the >> flag of a country in one of the RIR's jurisdictions. >> >> Should science fiction slide towards science reality and we start >> having nations on the moon, mars and in the asteroid belt, AFAIK ARIN >> is still the default registry for nations not claimed by another RIR. > > So can we get an exception to this rule if we put a US flag sticker on our > out of region routers? :) Sure, if they're in a U.S. embassy where treaties deem the property to be U.S. soil governed by U.S. law. Otherwise, no. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mike at iptrading.com Wed Sep 16 10:55:41 2015 From: mike at iptrading.com (Mike Burns) Date: Wed, 16 Sep 2015 10:55:41 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> Message-ID: <00e001d0f08f$c1ca3af0$455eb0d0$@iptrading.com> David says, "the time for RIRs being anything other than local language/time/etc is passed." If you agree, global policy changes will be needed to make it happen. Regards, Bill Herrin Hi Bill, Removing the needs test from paid transfers would solve this problem, too. Global policy not needed. On a related issue, still no speculation spotted in the IPv4 market despite needs-free transfers in RIPE for quite some time now. Regards, Mike From hannigan at gmail.com Wed Sep 16 11:33:37 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 16 Sep 2015 16:33:37 +0100 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <00e001d0f08f$c1ca3af0$455eb0d0$@iptrading.com> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> <00e001d0f08f$c1ca3af0$455eb0d0$@iptrading.com> Message-ID: On Wed, Sep 16, 2015 at 3:55 PM, Mike Burns wrote: > > David says, "the time for RIRs being anything other than local > language/time/etc is passed." If you agree, global policy changes will be > needed to make it happen. > > Regards, > Bill Herrin > > Hi Bill, > > Removing the needs test from paid transfers would solve this problem, too. > Global policy not needed. > On a related issue, still no speculation spotted in the IPv4 market despite > needs-free transfers in RIPE for quite some time now. > > We have a lesson learned with transfer policy dictating needs in other regions and other regions really disliking this. Global policies need to be agreed by all regions. Pushing global policy that continues to dictate requirements in other regions will fail. Global policy should be used to instruct the IANA, not to batter our fellow RIR's. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Wed Sep 16 13:25:48 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 16 Sep 2015 17:25:48 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: <00e001d0f08f$c1ca3af0$455eb0d0$@iptrading.com> References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> , <00e001d0f08f$c1ca3af0$455eb0d0$@iptrading.com> Message-ID: Mike is right, there isn't a need for needs testing anymore with runout. When ARIN does have blocks all they need to do is size it for the requesting organization. Also ARIN should start registering legacy blocks when they change hands with proper paperwork of course to keep the Database as accurate as possible. This would improve the supply for those who need resources as well. My two cents. Sent from my iPhone > On Sep 16, 2015, at 10:55 AM, Mike Burns wrote: > > > David says, "the time for RIRs being anything other than local > language/time/etc is passed." If you agree, global policy changes will be > needed to make it happen. > > Regards, > Bill Herrin > > Hi Bill, > > Removing the needs test from paid transfers would solve this problem, too. > Global policy not needed. > On a related issue, still no speculation spotted in the IPv4 market despite > needs-free transfers in RIPE for quite some time now. > > Regards, > Mike > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Wed Sep 16 14:44:12 2015 From: jcurran at arin.net (John Curran) Date: Wed, 16 Sep 2015 18:44:12 +0000 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> <6F3115DE-6E42-43AF-9CD6-B653E268CCC0@gmail.com> <00e001d0f08f$c1ca3af0$455eb0d0$@iptrading.com> Message-ID: <25D26068-9D57-4459-B637-6418A2C93430@corp.arin.net> > On Sep 16, 2015, at 1:25 PM, Steven Ryerse wrote: > > Mike is right, there isn't a need for needs testing anymore with runout. When ARIN does have blocks all they need to do is size it for the requesting organization. Also ARIN should start registering legacy blocks when they change hands with proper paperwork of course to keep the Database as accurate as possible. This would improve the supply for those who need resources as well. My two cents. Steven - For clarity, ARIN does perform transfers of legacy blocks with proper paperwork. What ARIN will not do is transfer an address block contrary to the community- developed policy. Changing policy as you suggest is not within ARIN?s purview, but is a task which lies with this community as it feels appropriate. Thanks, /John John Curran President and CEO ARIN From narten at us.ibm.com Fri Sep 18 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Sep 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201509180453.t8I4r2Em025795@rotala.raleigh.ibm.com> Total of 51 messages in the last 7 days. script run at: Fri Sep 18 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.65% | 9 | 19.22% | 81450 | jcurran at arin.net 15.69% | 8 | 17.70% | 74981 | hannigan at gmail.com 17.65% | 9 | 13.97% | 59195 | bill at herrin.us 7.84% | 4 | 10.74% | 45513 | david.huberman at microsoft.com 9.80% | 5 | 6.99% | 29604 | matthew at matthew.at 5.88% | 3 | 5.35% | 22665 | jlewis at lewis.org 5.88% | 3 | 4.90% | 20782 | owen at delong.com 3.92% | 2 | 6.32% | 26790 | scottleibrand at gmail.com 3.92% | 2 | 4.09% | 17345 | alfeh at me.com 3.92% | 2 | 3.18% | 13490 | aaron at wholesaleinternet.net 1.96% | 1 | 2.83% | 11995 | heather.skanks at gmail.com 1.96% | 1 | 1.65% | 6988 | narten at us.ibm.com 1.96% | 1 | 1.64% | 6939 | sryerse at eclipse-networks.com 1.96% | 1 | 1.41% | 5963 | mike at iptrading.com --------+------+--------+----------+------------------------ 100.00% | 51 |100.00% | 423700 | Total From bill at herrin.us Sat Sep 19 18:45:00 2015 From: bill at herrin.us (William Herrin) Date: Sat, 19 Sep 2015 18:45:00 -0400 Subject: [arin-ppml] Support for 2015-5 (Expand permitted out-of-region use of IPv4 space) In-Reply-To: References: <688387CF-C705-4D96-ADA5-31EF13D80EEA@delong.com> Message-ID: On Sat, Sep 19, 2015 at 6:26 PM, Mueller, Milton L wrote: >> -----Original Message----- >> All space vehicles (and airplanes and ships) are in one or another terrestrial >> country's legal jurisdiction. Your moon base would fly the flag of a country in >> one of the RIR's jurisdictions. > > This isn't true. Take a look at the 1966 Outer Space Treaty, which posits that " outer space is not subject to national appropriation by claim of sovereignty, by means of use or occupation, or by any other means." > http://www.unoosa.org/oosa/en/ourwork/spacelaw/treaties/introouterspacetreaty.html > > It isn't true of the oceans, either. The "high seas" are a sovereignty-free zone. Parts of Antarctica are, too. The territories are not subject to national appropriation. The hardware and facilities operate under the laws of the nation which sanctioned them. All that Apollo equipment left on the moon still belongs to the U.S. The ground it's sitting on does not. Get it? > Apparently, what you think of as science fiction is already here. Don't be such an insufferable smartass ... when you're wrong. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From info at arin.net Wed Sep 23 16:53:39 2015 From: info at arin.net (ARIN) Date: Wed, 23 Sep 2015 16:53:39 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - September 2015 Message-ID: <56031153.8040406@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 17 September 2015. The AC accepted the following as Draft Policies (they will be posted for discussion): ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks ARIN-prop-224 Minimum IPv6 Assignments ARIN-prop-225 Remove transfer language which only applied pre-exhaustion of IPv4 pool The AC is continuing to work on: Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations Draft Policy ARIN-2015-5: Out of region use Draft Policy ARIN-2015-6: Transfers and Multi-national Networks Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Sep 23 16:53:59 2015 From: info at arin.net (ARIN) Date: Wed, 23 Sep 2015 16:53:59 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Message-ID: <56031167.1010007@arin.net> Draft Policy ARIN-2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. Draft Policy ARIN-2015-9 is below and can be found at: https://www.arin.net/policy/proposals/2015_9.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Date: 23 September 2015 Problem statement: The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. Additionally, the 8.1 introduction section includes a perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. Policy statement: This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. Section 8.1 Principles: - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." Section 8.2 Mergers and Acquisitions: - Change the 4th bullet from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Change the first bullet under "Conditions on recipient of the transfer" from: "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." to: "The recipient must sign an RSA." - Change the 2nd bullet under "Conditions on recipient of the transfer" from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." Section 8.4 Inter-RIR Transfers to Specified Recipients: - Change the introductory language from: "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." to: "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." - Change the 2nd bullet under "Conditions on recipient of the transfer" from: "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." to: "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." Comments: a. Timetable for implementation: Immediate b. Anything else As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. From info at arin.net Wed Sep 23 16:54:13 2015 From: info at arin.net (ARIN) Date: Wed, 23 Sep 2015 16:54:13 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments Message-ID: <56031175.5040102@arin.net> Draft Policy ARIN-2015-10 Minimum IPv6 Assignments On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy. Draft Policy ARIN-2015-10 is below and can be found at: https://www.arin.net/policy/proposals/2015_10.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-10 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-10 Minimum IPv6 Assignments Date: 23 September 2015 Problem Statement: ISPs may believe that they have an incentive to obtain smaller blocks than they really need, and once they receive their allocation may subsequently issue blocks smaller than their customers may need in the future. This policy seeks to encourage the correct behavior by reiterating the smallest reasonable sub-allocation size and by discounting any space which has been subdivided more finely from any future utilization analysis. Policy statement: Modify section 2.15 from "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48)." to "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites. A /48 is recommended as this smallest block size. In no case shall a provider assignment unit for the purpose of this policy be smaller than /56." Modify section 2.16.1 from "A provider assignment unit shall be considered fully utilized when it is assigned to an end-site" to "A provider assignment unit shall be considered fully utilized when it is assigned in full (or as part of a larger aggregate) to a single end-site. If a provider assignment unit (which shall be no smaller than /56) is split and assigned to multiple end-sites that entire provider assignment unit shall be considered NOT utilized." Comments: Timetable for implementation: IMMEDIATE From info at arin.net Wed Sep 23 16:54:30 2015 From: info at arin.net (ARIN) Date: Wed, 23 Sep 2015 16:54:30 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool Message-ID: <56031186.5040407@arin.net> Draft Policy ARIN-2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-225 Remove transfer language which only applied pre-exhaustion of IPv4 pool" as a Draft Policy. Draft Policy ARIN-2015-11 is below and can be found at: https://www.arin.net/policy/proposals/2015_11.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-11 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool Date: 23 September 2015 Problem Statement: The current policies in NRPM sections 8.3, and 8.4 include language which is in effect "until exhaustion." As ARIN is no longer able to fulfil IPv4 requests (per 01 July 2015 press release https://www.arin.net/about_us/media/releases/20150701.html), exhaustion has effectively occurred. This proposal serves to remove the outdated language from the NRPM. Policy statement: Remove sections of the NRPM which were only affective until IPv4 pool exhaustion occurred, as follows: Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Remove entirely the second bullet which reads "The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Section 8.4 Inter-RIR Transfers to Specified Recipients: - Remove entirely the third bullet which reads "Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Comments: Timetable for implementation: Immediate From info at arin.net Wed Sep 23 17:03:08 2015 From: info at arin.net (ARIN) Date: Wed, 23 Sep 2015 17:03:08 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-5: Out of region use - revised In-Reply-To: <55F0365D.6010409@arin.net> References: <55F0365D.6010409@arin.net> Message-ID: <5603138C.5050008@arin.net> ARIN-2015-5 has been revised. ARIN staff provided a staff and legal assessment to the ARIN Advisory Council (AC) on 18 August. The AC revised the policy text, staff revised their assessment, and then the AC made some editorial changes to the policy text (which were suggested by staff). You are encouraged to discuss the merits and your concerns of Draft Policy 2015-5 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community ARIN-2015-5 is below and can be found at: https://www.arin.net/policy/proposals/2015_5.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-5 Out of region use Date: 17 September 2015 Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use or loosen controls and totally authorize such use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows: * IPv4: At least a /22 used in region * IPv6: At least a /44 used in region * ASN: At least one ASN present on one or more peering sessions and/or routers within the region. A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. * Demonstrating that the entity provides services to and solicits sales from residents of the ARIN region. * Demonstrating that the entity holds periodic meetings in the ARIN region. * Demonstrating that the entity raises investment capital from investors in the ARIN region. * Demonstrating that the entity has a registered corporation in the ARIN region, although this factor on its own shall not be sufficient. * Other fact based criterion that the entity considers appropriate and submits for ARIN's review. The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to obtain from the applicant a listing of all the applicant's number holdings in the region(s) of proposed use, when there are factual reasons to support the request. Comments: a) Timetable for implementation: Various iterations of this policy have been presented and debated by ARIN for well over a year now. Given the amount of time that has already been spent on developing a policy, ideally, this policy would be implemented as soon as possible. b) Explanation of draft policy: The draft policy addresses both the problem statement as well as the concerns raised at ARIN 35 by participants as well as ARIN counsel. Firstly, the draft policy addresses the concerns of ARIN counsel as well as some of the participants at ARIN 35 by ensuring that anyone requesting numbered resources from ARIN has a real and substantial connection with the ARIN region. This should go a long way to addressing concerns about fraud, legal liability, and interference with the jurisdiction of other RIRs. In addition, by placing the burden of proof for demonstrating a real and substantial connection with the ARIN region on the applicant, the amount of work required of ARIN staff to apply the policy will be reduced. The factors noted above are suggestions that an entity may use to demonstrate to ARIN that it is carrying on business in the ARIN region in a meaningful manner. These factors are all indicative, some more than others, that an entity has a real and substantial connection to the ARIN region through the carrying on of business in the ARIN region in a meaningful manner. Not all of the factors will apply in a given case and proving a single factor may not be enough to satisfy ARIN that an entity is carrying on business in the region in a meaningful manner. The list of factors is meant to be quite broad, including an open-ended factor, in order to capture the diversity of businesses that operate in the ARIN region and that may justifiably require numbered resources from ARIN. This approach is very similar to the practical method that courts typically apply to assess whether parties have a sufficient connection to a jurisdiction so as to require them to submit themselves to the courts of that jurisdiction. This draft policy is a substantial improvement over the previous version of ARIN-2014-1 in terms of reducing the overall risk to the community by requiring a real and substantial connection between an entity requesting resources and the ARIN region. ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-5 OUT OF REGION USE Date of Assessment: 17 September 2015 ___ 1. Summary (Staff Understanding) This proposal would allow an organization to receive Internet number resources from ARIN for use out of region as long as the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. In addition, the applicant must have a real and substantial connection with the ARIN region, which the applicant shall be responsible for proving. ___ 2. Comments A. ARIN Staff Comments This policy would increase the complexity of ARIN staff review work in request cases that fit the profile of this policy. There would in an increase in the vetting and utilization verification work currently conducted by ARIN staff. This policy would be placed in the NRPM as section 9, "Out of Region Use". B. ARIN General Counsel ? Legal Assessment If the policy is enacted it will require ARIN staff to work with counsel with some attendant increase in costs in the first year to manage implementation. The policy is consistent with standard legal principles routinely utilized in the ARIN region. The policy creates no material legal risks. ___ 3. Resource Impact From a request review standpoint, implementation of this policy would require additional review steps for Internet number resource requests. It could have future staffing implications based on the amount of additional work the policy could present. It is estimated that implementation could occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training Implementation of this policy may allow for registrations in the ARIN database that require unicode character sets. From an engineering standpoint, implementation of this policy could have a major resource impact. It is estimated that implementation would occur within 12 months, instead of the 3 months cited above, after ratification by the ARIN Board of Trustees if ARIN is required to support unicode character sets. The following would be needed in order to implement: * Engineering: Engineering efforts to handle out of region business rules may be substantial as our system only supports ascii now. If there is a need for unicode character sets, then there is a substantial amount of work required to upgrade the DB and applications to support unicode. Additionally, we would need to discuss how to display unicode characters in port 43 whois. ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2015-5 (September 9, 2015, version) Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows: * IPv4: At least a /22 used in region * IPv6: At least a /44 used in region * ASN: At least one ASN present on one or more peering sessions and/or routers within the region. A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner, whether for or not for profit. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. * Demonstrating that the entity provides services to or solicits sales from residents of the ARIN region. * Demonstrating that the entity holds annual meetings in the ARIN region. * Demonstrating that the entity raises investment capital from investors in the ARIN region. * Demonstrating that the entity has a registered office in the ARIN region, although this factor on its own shall not be sufficient. * Any other method that the entity considers appropriate. The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. On 9/9/15 9:38 AM, ARIN wrote: > ARIN-2015-5 has been revised. > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-5 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > ARIN-2015-5 is below and can be found at: > https://www.arin.net/policy/proposals/2015_5.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2015-5 > Out of region use > > Date: 9 September 2015 > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out of region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on > this issue has explored several options to restrict or otherwise limit > out of region use. None of these options have gained consensus within > the community. The next logical option is a proposal that clearly > permits out of region use while addressing the key concerns expressed > about unlimited openness to out of region use and enables ARIN staff to > implement the policy efficiently. > > Policy statement: > > Create new Section X: ARIN registered resources may be used outside the > ARIN service region. > > Out of region use of ARIN registered resources are valid justification > for additional number resources, provided that the applicant has a real > and substantial connection with the ARIN region which applicant must > prove (as described below) and is using the same type of resources (with > a delegation lineage back to an ARIN allocation or assignment) within > the ARIN service region as follows: > > * IPv4: At least a /22 used in region > * IPv6: At least a /44 used in region > * ASN: At least one ASN present on one or more peering sessions and/or > routers within the region. > > A real and substantial connection shall be defined as carrying on > business in the ARIN region in a meaningful manner, whether for or not > for profit. The determination as to whether an entity is carrying on > business in the ARIN region in a meaningful manner shall be made by > ARIN. Simply being incorporated in the ARIN region shall not be > sufficient, on its own, to prove that an entity is carrying on business > in the ARIN region in a meaningful manner. Methods that entities may > consider using, including cumulatively, to prove that they are carrying > on business in the ARIN region in a meaningful manner include: > * Demonstrating a physical presence in the ARIN region through a bricks > and mortar location that is actually used for the purposes of conducting > business in the ARIN region in a meaningful manner. That is to say, the > location is not merely a registered office that serves no other business > purpose. > * Demonstrating that the entity has staff in the ARIN region. The > greater the number of staff, the stronger this connecting factor is. > * Demonstrating that the entity holds assets in the ARIN region. The > greater the asset value, the stronger this connecting factor is. > * Demonstrating that the entity provides services to or solicits sales > from residents of the ARIN region. > * Demonstrating that the entity holds annual meetings in the ARIN region. > * Demonstrating that the entity raises investment capital from investors > in the ARIN region. > * Demonstrating that the entity has a registered office in the ARIN > region, although this factor on its own shall not be sufficient. > * Any other method that the entity considers appropriate. > The weight accorded to any of the above-noted factors, if any, shall be > determined solely by ARIN. > > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR's service region, an > officer of the application must attest that the same services and > facilities have not been used as the basis for a resource request in the > other region(s). ARIN reserves the right to request a listing of all the > applicant's number holdings in the region(s) of proposed use, but this > should happen only when there are significant reasons to suspect > duplicate requests. > > Comments: > > a) Timetable for implementation: Various iterations of this policy have > been presented and debated by ARIN for well over a year now. Given the > amount of time that has already been spent on developing a policy, > ideally, this policy would be implemented as soon as possible. > b) Explanation of draft policy: The draft policy addresses both the > problem statement as well as the concerns raised at ARIN 35 by > participants as well as ARIN counsel. > Firstly, the draft policy addresses the concerns of ARIN counsel as well > as some of the participants at ARIN 35 by ensuring that anyone > requesting numbered resources from ARIN has a real and substantial > connection with the ARIN region. This should go a long way to addressing > concerns about fraud, legal liability, and interference with the > jurisdiction of other RIRs. > In addition, by placing the burden of proof for demonstrating a real and > substantial connection with the ARIN region on the applicant, the amount > of work required of ARIN staff to apply the policy will be reduced. > The factors noted above are suggestions that an entity may use to > demonstrate to ARIN that it is carrying on business in the ARIN region > in a meaningful manner. These factors are all indicative, some more than > others, that an entity has a real and substantial connection to the ARIN > region through the carrying on of business in the ARIN region in a > meaningful manner. Not all of the factors will apply in a given case and > proving a single factor may not be enough to satisfy ARIN that an entity > is carrying on business in the region in a meaningful manner. The list > of factors is meant to be quite broad, including an open-ended factor, > in order to capture the diversity of businesses that operate in the ARIN > region and that may justifiably require numbered resources from ARIN. > This approach is very similar to the practical method that courts > typically apply to assess whether parties have a sufficient connection > to a jurisdiction so as to require them to submit themselves to the > courts of that jurisdiction. > > This draft policy is a substantial improvement over the previous version > of ARIN-2014-1 in terms of reducing the overall risk to the community by > requiring a real and substantial connection between an entity requesting > resources and the ARIN region. > > ##### > > ARIN STAFF & LEGAL ASSESSMENT > > Draft Policy ARIN-2015-5 > OUT OF REGION USE > https://www.arin.net/policy/proposals/2015_5.html > > Date of Assessment: 18 August 2015 > > ___ > 1. Summary (Staff Understanding) > > This proposal would allow an organization to receive Internet number > resources from ARIN for use out of region as long as the applicant is > currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, > or 1 ASN within the ARIN service region, respectively. In addition, the > applicant must have a real and substantial connection with the ARIN > region, which the applicant shall be responsible for proving. > > ___ > 2. Comments > > A. ARIN Staff Comments > > This policy would increase the complexity of ARIN staff review work in > request cases that fit the profile of this policy. There would in an > increase in the vetting and utilization verification work currently > conducted by ARIN staff. > > There are conflicting instructions to ARIN staff in this policy text. > Specifically, the text says, "The determination as to whether an entity > is carrying on business in the ARIN region in a meaningful manner shall > be made by ARIN." Then at the end of the examples given, the text > states, "Any other method that the entity considers appropriate." This > implies that ARIN staff may have to accept anything presented by an > organization as a method of proving a "real and substantial connection > with the ARIN region." > > It is not clear if the utilized /22, /44 or AS Number are required to > have been issued by ARIN or is it allowable to be from another RIR. > > This policy would be placed in the NRPM as section 9, "Out of Region Use". > > B. ARIN General Counsel ??? Legal Assessment > > If the policy is enacted it will require ARIN staff to work with counsel > with some attendant increase in costs in the first year to manage > implementation. The policy is consistent with standard legal principles > routinely utilized in the ARIN region. The policy creates no material > legal risks. > > ___ > 3. Resource Impact > This policy could have a major resource impact from an implementation > aspect. It is estimated that implementation would occur within 12 months > after ratification by the ARIN Board of Trustees. The following would be > needed in order to implement: > > * Updated guidelines and internal procedures > * Staff training > * Engineering: Engineering efforts to handle out of region business > rules may besubstantial as our system only supports ascii now. If there > is a need for unicode character sets, then there is a substantial amount > of work required to upgrade the DB and applications to support unicode. > Additionally, we would need to discuss how to display unicode characters > in port 43 whois. There may be additional tools needed by RSD staff to > measure in region/out of region use. > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2015-5 > > Date: 23 June 2015 > > Problem statement: > Current policy neither clearly forbids nor clearly permits out or region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on > this issue has explored several options to restrict or otherwise limit > out of region use. None of these options have gained consensus within > the community. The next logical option is a proposal that clearly > permits out of region use while addressing the key concerns expressed > about unlimited openness to out of region use and enables ARIN staff to > implement the policy efficiently. > > Policy statement: > Create new Section X: > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at least > the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN > service region, respectively. In addition, the applicant must have a > real and substantial connection with the ARIN region, which the > applicant shall be responsible for proving. > A real and substantial connection shall be defined as carrying on > business in the ARIN region in a meaningful manner, whether for or not > for profit. The determination as to whether an entity is carrying on > business in the ARIN region in a meaningful manner shall be made by > ARIN. Simply being incorporated in the ARIN region shall not be > sufficient, on its own, to prove that an entity is carrying on business > in the ARIN region in a meaningful manner. Methods that entities may > consider using, including cumulatively, to prove that they are carrying > on business in the ARIN region in a meaningful manner include: > * Demonstrating a physical presence in the ARIN region through a bricks > and mortar location that is actually used for the purposes of conducting > business in the ARIN region in a meaningful manner. That is to say, the > location is not merely a registered office that serves no other business > purpose. > * Demonstrating that the entity has staff in the ARIN region. The > greater the number of staff, the stronger this connecting factor is. > * Demonstrating that the entity holds assets in the ARIN region. The > greater the asset value, the stronger this connecting factor is. > * Demonstrating that the entity provides services to or solicits sales > from residents of the ARIN region. > * Demonstrating that the entity holds annual meetings in the ARIN region. > * Demonstrating that the entity raises investment capital from investors > in the ARIN region. > * Demonstrating that the entity has a registered office in the ARIN > region, although this factor on its own shall not be sufficient. > * Any other method that the entity considers appropriate. > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR's service region, the > officer of the applicant must attest that the same services and > facilities have not been used as the basis for a resource request in the > other region(s). ARIN reserves the right to request a listing of all the > applicant's number holdings in the region(s) of proposed use, but this > should happen only when there are significant reasons to suspect > duplicate requests. > > Comments: > a) Timetable for implementation: Various iterations of this policy have > been presented and debated by ARIN for well over a year now. Given the > amount of time that has already been spent on developing a policy, > ideally, this policy would be implemented as soon as possible. > b) Explanation of draft policy: The draft policy addresses both the > problem statement as well as the concerns raised at ARIN 35 by > participants as well as ARIN counsel. > Firstly, the draft policy addresses the concerns of ARIN counsel as well > as some of the participants at ARIN 35 by ensuring that anyone > requesting numbered resources from ARIN has a real and substantial > connection with the ARIN region. This should go a long way to addressing > concerns about fraud, legal liability, and interference with the > jurisdiction of other RIRs. > In addition, by placing the burden of proof for demonstrating a real and > substantial connection with the ARIN region on the applicant, the amount > of work required of ARIN staff to apply the policy will be reduced. > The factors noted above are suggestions that an entity may use to > demonstrate to ARIN that it is carrying on business in the ARIN region > in a meaningful manner. These factors are all indicative, some more than > others, that an entity has a real and substantial connection to the ARIN > region through the carrying on of business in the ARIN region in a > meaningful manner. Not all of the factors will apply in a given case and > proving a single factor may not be enough to satisfy ARIN that an entity > is carrying on business in the region in a meaningful manner. The list > of factors is meant to be quite broad, including an open-ended factor, > in order to capture the diversity of businesses that operate in the ARIN > region and that may justifiably require numbered resources from ARIN. > This approach is very similar to the practical method that courts > typically apply to assess whether parties have a sufficient connection > to a jurisdiction so as to require them to submit themselves to the > courts of that jurisdiction. > This draft policy is a substantial improvement over the previous version > of ARIN-2014-1 in terms of reducing the overall risk to the community by > requiring a real and substantial connection between an entity requesting > resources and the ARIN region. From info at arin.net Wed Sep 23 17:12:13 2015 From: info at arin.net (ARIN) Date: Wed, 23 Sep 2015 17:12:13 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-6: Transfers and Multi-national Networks - revised In-Reply-To: <55E5D9DC.5020403@arin.net> References: <5589BC46.20403@arin.net> <55E5D9DC.5020403@arin.net> Message-ID: <560315AD.5000209@arin.net> On 1 September 2015 the ARIN Advisory Council revised 2015-6. Below you will find the the updated ARIN staff assessment. ARIN-2015-5 is below and can be found at: https://www.arin.net/policy/proposals/2015_5.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-6 TRANSFERS AND MULTI-NATIONAL NETWORKS Date of Assessment: 15 September 2015 ___ 1. Summary (Staff Understanding) This proposal states that when evaluating transfer requests, ARIN will not consider the geographic location where an organization is utilizing, or will utilize, its ARIN-registered addresses if that organization, its parent, or a subsidiary are able to satisfy each of the four stated criteria. ___ 2. Comments A. ARIN Staff Comments ? During the course of a transfer request, staff will consider and review the utilization of any block issued by ARIN to that organization, regardless of whether that address space is being used outside of the ARIN region. ? This policy enables organizations to qualify as a recipient for 8.3 or 8.4 transfers in the ARIN region when they might not have otherwise been able to do so. ARIN staff would now be able to consider their global utilization, instead of only their in-ARIN region use. ? One of the elements ARIN staff uses to determine 24-month need for an organization is their historical utilization rate. This proposal allows organizations to justify a larger 24-month needs based qualification, because staff will consider their utilization globally instead of just what was used inside the ARIN region. ? This would be placed in a new section of the NRPM called "8.5 Additional Transfer Policies". ? This policy could be implemented as written. B. ARIN General Counsel ? Legal Assessment No material legal issues. If the policy is enacted it will require ARIN staff to work with counsel with some attendant increase in costs in the first year to manage implementation. ___ 3. Resource Impact From a request review standpoint, implementation of this policy would have minimal resource impact. However, it could have future staffing implications based on the amount of additional work the policy could present. It is estimated that implementation could occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training Implementation of this policy may allow for registrations in the ARIN database that require unicode character sets. From an engineering standpoint, implementation of this policy could have a major resource impact. It is estimated that implementation would occur within 12 months, instead of the 3 months cited above, after ratification by the ARIN Board of Trustees if ARIN is required to support unicode character sets. The following would be needed in order to implement: * Engineering: Engineering efforts to handle out of region business rules may be substantial as our system only supports ascii now. If there is a need for unicode character sets, then there is a substantial amount of work required to upgrade the DB and applications to support unicode. Additionally, we would need to discuss how to display unicode characters in port 43 whois. ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2015-6 Problem statement: Some organizations within the ARIN region are currently unable to receive IPv4 space via transfer based on current ARIN policy, which prohibits address space used outside of the ARIN region from being considered efficiently utilized. This proposal would allow organizations with a strong and long-standing presence in the ARIN region to be able to receive number resources via transfer for their global operations. Policy statement: When evaluating transfer requests, ARIN will not consider the geographic location where an organization is utilizing, or will utilize, its ARIN-registered addresses if that organization, its parent, or a subsidiary: 1. has been an ARIN customer for at least 36 months; AND 2. is currently in good standing with ARIN; AND 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND 4. can demonstrate it has a meaningful business that operates in the ARIN region. On 9/1/15 1:01 PM, ARIN wrote: > ARIN-2015-6 has been revised. > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-6 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > ARIN-2015-6 is below and can be found at: > https://www.arin.net/policy/proposals/2015_6.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2015-6 > Transfers and Multi-national Networks > > Date: 25 August 2015 > > Problem statement: > > Some organizations within the ARIN region are currently unable to > receive IPv4 space via transfer based on current ARIN policy, which > prohibits address space used outside of the ARIN region from being > considered efficiently utilized. This proposal would allow organizations > with a strong and long-standing presence in the ARIN region to be able > to receive number resources via transfer for their global operations. > > Policy statement: > > When evaluating transfer requests, ARIN will not consider the geographic > location where an organization is utilizing, or will utilize, its > ARIN-registered addresses if that organization, its parent, or a > subsidiary: > > 1. has been an ARIN customer for at least 36 months; AND > > 2. is currently in good standing with ARIN; AND > > 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND > > 4. can demonstrate it has a meaningful business that operates in the > ARIN region. > > Comments: > > Timetable for implementation: Immediate > > ##### > > ARIN STAFF & LEGAL ASSESSMENT > > Draft Policy ARIN-2015-6 > TRANSFERS AND MULTI-NATIONAL NETWORKS > https://www.arin.net/policy/proposals/2015_6.html > > Date of Assessment: 18 August 2015 > > ___ > 1. Summary (Staff Understanding) > > This proposal states that when evaluating transfer requests, ARIN will > not consider the geographic location where an organization is utilizing > its ARIN-registered addresses if that organization, its parent, or a > subsidiary are able to satisfy each of the four stated criteria. > > ___ > 2. Comments > > A. ARIN Staff Comments > > ?During the course of a transfer request, staff will consider and review > the utilization of any block issued by ARIN to that organization, > regardless of whether that address space is being used outside of the > ARIN region. > ?This policy enables organizations to qualify as a recipient for 8.3 or > 8.4 transfers in the ARIN region when they might not have otherwise been > able to do so. ARIN staff would now be able to consider their global > utilization, instead of only their in-ARIN region use. > ?One of the elements ARIN staff uses to determine 24-month need for an > organization is their historical utilization rate. This proposal allows > organizations to justify a larger 24-month needs based qualification, > because staff will consider their utilization globally instead of just > what was used inside the ARIN region. > ?The policy proposal text appears to not align with the intent of the > policy as described in the problem statement. This proposal changes how > ARIN considers prior utilization of IPv4 address space, but does not > specify that newly received resources can be used outside of the region. > Existing policy and practice would dictate ARIN continues to issue space > for use in the ARIN region. We note that 2015-5, if adopted, could > change this. > ?This would be placed in a new section of the NRPM called "8.5 > Additional Transfer Policies". > ?This policy could be implemented as written. > > B. ARIN General Counsel ? Legal Assessment > > No material legal issues. If the policy is enacted it will require ARIN > staff to work with counsel with some attendant increase in costs in the > first year to manage implementation. > > ___ > 3. Resource Impact > This policy would have minimal resource impact from an implementation > aspect. However, it could have future staffing implications based on the > amount of additional work the policy could present. 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: > > * Updated guidelines and internal procedures > * Staff training > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2015-6 > > Date: 23 June 2015 > > Problem statement: > Some organizations within the ARIN region are currently unable to > receive IPv4 space via transfer based on current ARIN policy, which > prohibits address space used outside of the ARIN region from being > considered efficiently utilized. This proposal would allow organizations > with a strong and long-standing presence in the ARIN region to be able > to receive number resources via transfer for their global operations. > Policy statement: > When evaluating transfer requests, ARIN will not consider the geographic > location where an organization is utilizing its ARIN-registered > addresses if that organization, its parent, or a subsidiary: > 1. has been an ARIN customer for at least 36 months; AND > 2. is currently in good standing with ARIN; AND > 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND > 4. can demonstrate it has a meaningful business that operates in the > ARIN region. > From lsawyer at gci.com Thu Sep 24 14:55:26 2015 From: lsawyer at gci.com (Leif Sawyer) Date: Thu, 24 Sep 2015 18:55:26 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <56031167.1010007@arin.net> References: <56031167.1010007@arin.net> Message-ID: Now that we've reached the magic ZERO in the free pool, what does the community think about this new draft policy? Should ARIN begin the process of streamlining the IPv4 policy so that it is geared more toward the transfer market, and remove "need" as a criteria in certain sections of the NRPM to increase the database accuracy? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 23, 2015 12:54 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Draft Policy ARIN-2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. Draft Policy ARIN-2015-9 is below and can be found at: https://www.arin.net/policy/proposals/2015_9.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Date: 23 September 2015 Problem statement: The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. Additionally, the 8.1 introduction section includes a perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. Policy statement: This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. Section 8.1 Principles: - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." Section 8.2 Mergers and Acquisitions: - Change the 4th bullet from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Change the first bullet under "Conditions on recipient of the transfer" from: "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." to: "The recipient must sign an RSA." - Change the 2nd bullet under "Conditions on recipient of the transfer" from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." Section 8.4 Inter-RIR Transfers to Specified Recipients: - Change the introductory language from: "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." to: "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." - Change the 2nd bullet under "Conditions on recipient of the transfer" from: "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." to: "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." Comments: a. Timetable for implementation: Immediate b. Anything else As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Sep 24 15:09:31 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Sep 2015 12:09:31 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> Message-ID: Short answer: NO Longer answer: Finance alone does not reflect all community values. Eliminating needs-based evaluation for transfers will foster an environment open to speculation and other artifice used to maximize the monetization of address resources without providing the benefit to the community of maximizing utilization. In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the long run in favor of financial manipulation. Owen > On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: > > Now that we've reached the magic ZERO in the free pool, what does the community > think about this new draft policy? > > Should ARIN begin the process of streamlining the IPv4 policy so that it is > geared more toward the transfer market, and remove "need" as a criteria in > certain sections of the NRPM to increase the database accuracy? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Wednesday, September 23, 2015 12:54 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > On 17 September 2015 the ARIN Advisory Council (AC) accepted > "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > > Draft Policy ARIN-2015-9 is below and can be found at: > https://www.arin.net/policy/proposals/2015_9.html > > You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > Date: 23 September 2015 > > Problem statement: > > The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. > Additionally, the 8.1 introduction section includes a perceived "threat" > of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. > > Policy statement: > > This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. > > Section 8.1 Principles: > > - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." > > Section 8.2 Mergers and Acquisitions: > > - Change the 4th bullet from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." > > - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > > - Change the first bullet under "Conditions on recipient of the transfer" from: > > "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." > > to: > > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." > > Section 8.4 Inter-RIR Transfers to Specified Recipients: > > - Change the introductory language from: > > "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." > > to: > > "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > from: > > "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." > > to: > > "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." > > - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and > ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. > > The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mike at iptrading.com Thu Sep 24 15:34:59 2015 From: mike at iptrading.com (Mike Burns) Date: Thu, 24 Sep 2015 15:34:59 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks References: <56031167.1010007@arin.net> Message-ID: ----- Original Message ----- From: "Leif Sawyer" > Should ARIN begin the process of streamlining the IPv4 policy so that it > is > geared more toward the transfer market, and remove "need" as a criteria in > certain sections of the NRPM to increase the database accuracy? > > Hi Leif, Yes. The community distributed the addresses appropriately, IMO. Now it's time to step back and let the market work to conserve addresses and bring them into their highest and best use. And reap the rewards in increased Whois acccuracy, more efficient transfers, and less cost to the ARIN community. Regards, Mike Burns From SRyerse at eclipse-networks.com Thu Sep 24 15:36:38 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 24 Sep 2015 19:36:38 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> Message-ID: <12729e54a9ef44a8bddf05036b66c5ab@eni-mail1.eclipse-networks.com> I couldn't agree more! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Thursday, September 24, 2015 3:35 PM To: Leif Sawyer ; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks ----- Original Message ----- From: "Leif Sawyer" > Should ARIN begin the process of streamlining the IPv4 policy so that > it is geared more toward the transfer market, and remove "need" as a > criteria in certain sections of the NRPM to increase the database > accuracy? > > Hi Leif, Yes. The community distributed the addresses appropriately, IMO. Now it's time to step back and let the market work to conserve addresses and bring them into their highest and best use. And reap the rewards in increased Whois acccuracy, more efficient transfers, and less cost to the ARIN community. Regards, Mike Burns _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From springer at inlandnet.com Thu Sep 24 15:37:11 2015 From: springer at inlandnet.com (John Springer) Date: Thu, 24 Sep 2015 12:37:11 -0700 (PDT) Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <56031175.5040102@arin.net> References: <56031175.5040102@arin.net> Message-ID: Hi PPML, There have been a number of public discussions regarding the ins and outs of IPV6 subnet allocation. One such starts here: http://mailman.nanog.org/pipermail/nanog/2014-October/070339.html My recollection of the outcomes of these discussions is a sort of rough consensus that /48 is a good idea and indeed, many of the calculations used to evaluate what size of V6 block an org should request, start with that assumtion. ARIN (speaking as myself, not a member of any group and roughly paraphrasing someone more authoritative than I) does not dictate what you do with addresses after the allocation has been received. In some cases, ARIN looks at what you do with addresses when you come back for more and might not give them to you depending on what choices you have made. That is what this Draft Proposal seeks to do. I think it is clear that we can do that. Should we? And if you have an opinion of no, are you able to say because it is technically unsound or unfair and partial? John Springer On Wed, 23 Sep 2015, ARIN wrote: > Draft Policy ARIN-2015-10 > Minimum IPv6 Assignments > > On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 > Minimum IPv6 Assignments" as a Draft Policy. > > Draft Policy ARIN-2015-10 is below and can be found at: > https://www.arin.net/policy/proposals/2015_10.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-10 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2015-10 > Minimum IPv6 Assignments > > Date: 23 September 2015 > > Problem Statement: > > ISPs may believe that they have an incentive to obtain smaller blocks than > they really need, and once they receive their allocation may subsequently > issue blocks smaller than their customers may need in the future. This policy > seeks to encourage the correct behavior by reiterating the smallest > reasonable sub-allocation size and by discounting any space which has been > subdivided more finely from any future utilization analysis. > > Policy statement: > > Modify section 2.15 from "When applied to IPv6 policies, the term "provider > assignment unit" shall mean the prefix of the smallest block a given ISP > assigns to end sites (recommended /48)." to "When applied to IPv6 policies, > the term "provider assignment unit" shall mean the prefix of the smallest > block a given ISP assigns to end sites. A /48 is recommended as this smallest > block size. In no case shall a provider assignment unit for the purpose of > this policy be smaller than /56." > > Modify section 2.16.1 from "A provider assignment unit shall be considered > fully utilized when it is assigned to an end-site" to "A provider assignment > unit shall be considered fully utilized when it is assigned in full (or as > part of a larger aggregate) to a single end-site. If a provider assignment > unit (which shall be no smaller than /56) is split and assigned to multiple > end-sites that entire provider assignment unit shall be considered NOT > utilized." > > Comments: > 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 elvis at velea.eu Thu Sep 24 15:51:29 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 24 Sep 2015 22:51:29 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <12729e54a9ef44a8bddf05036b66c5ab@eni-mail1.eclipse-networks.com> References: <56031167.1010007@arin.net> <12729e54a9ef44a8bddf05036b66c5ab@eni-mail1.eclipse-networks.com> Message-ID: <56045441.2040106@velea.eu> +1 Keeping needs basis in the NRPM will only drive the transfers underground. Some are already using all kind of financial tricks (futures contracts, lease contracts, etc) and are waiting for the needs basis criteria to be removed from NRPM in order to register the transfers in the ARIN Registry. The Registry/Whois will win most from the removal of needs basis from the NRPM and process streamlining. regards, elvis On 24/09/15 22:36, Steven Ryerse wrote: > I couldn't agree more! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns > Sent: Thursday, September 24, 2015 3:35 PM > To: Leif Sawyer ; arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > ----- Original Message ----- > From: "Leif Sawyer" > >> Should ARIN begin the process of streamlining the IPv4 policy so that >> it is geared more toward the transfer market, and remove "need" as a >> criteria in certain sections of the NRPM to increase the database >> accuracy? >> >> > Hi Leif, > > Yes. The community distributed the addresses appropriately, IMO. > Now it's time to step back and let the market work to conserve addresses and bring them into their highest and best use. > And reap the rewards in increased Whois acccuracy, more efficient transfers, and less cost to the ARIN community. > > Regards, > Mike Burns > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Sep 24 16:04:35 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Sep 2015 13:04:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> Message-ID: <29286955-3FFD-417B-98D5-B44A5183DB7D@delong.com> > On Sep 24, 2015, at 12:37 , John Springer wrote: > > Hi PPML, > > There have been a number of public discussions regarding the ins and outs of IPV6 subnet allocation. One such starts here: > http://mailman.nanog.org/pipermail/nanog/2014-October/070339.html > > My recollection of the outcomes of these discussions is a sort of rough consensus that /48 is a good idea and indeed, many of the calculations used to evaluate what size of V6 block an org should request, start with that assumtion. > > ARIN (speaking as myself, not a member of any group and roughly paraphrasing someone more authoritative than I) does not dictate what you do with addresses after the allocation has been received. In some cases, ARIN looks at what you do with addresses when you come back for more and might not give them to you depending on what choices you have made. > > That is what this Draft Proposal seeks to do. > > I think it is clear that we can do that. Should we? > > And if you have an opinion of no, are you able to say because it is technically unsound or unfair and partial? This isn?t really necessary, John. A proposal must be fair, technically sound, and have support of the community in order to be adopted. Just because it is technically sound and/or fair does not mean that the community must support it. People are free to reject a policy for any reason, though I admit a bias in favor of at least some rationale for rejection. Owen > > John Springer > > On Wed, 23 Sep 2015, ARIN wrote: > >> Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy. >> >> Draft Policy ARIN-2015-10 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_10.html >> >> You are encouraged to discuss the merits and your concerns of Draft >> Policy 2015-10 on the Public Policy Mailing List. >> >> The AC will evaluate the discussion in order to assess the conformance >> of this draft policy with ARIN's Principles of Internet Number Resource >> Policy as stated in the PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (PDP) can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> Date: 23 September 2015 >> >> Problem Statement: >> >> ISPs may believe that they have an incentive to obtain smaller blocks than they really need, and once they receive their allocation may subsequently issue blocks smaller than their customers may need in the future. This policy seeks to encourage the correct behavior by reiterating the smallest reasonable sub-allocation size and by discounting any space which has been subdivided more finely from any future utilization analysis. >> >> Policy statement: >> >> Modify section 2.15 from "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48)." to "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites. A /48 is recommended as this smallest block size. In no case shall a provider assignment unit for the purpose of this policy be smaller than /56." >> >> Modify section 2.16.1 from "A provider assignment unit shall be considered fully utilized when it is assigned to an end-site" to "A provider assignment unit shall be considered fully utilized when it is assigned in full (or as part of a larger aggregate) to a single end-site. If a provider assignment unit (which shall be no smaller than /56) is split and assigned to multiple end-sites that entire provider assignment unit shall be considered NOT utilized." >> >> Comments: >> 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. >> >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 elvis at velea.eu Thu Sep 24 16:12:55 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 24 Sep 2015 23:12:55 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> Message-ID: <56045947.9070201@velea.eu> Hi Owen, On 24/09/15 22:09, Owen DeLong wrote: > Short answer: NO > > Longer answer: > > Finance alone does not reflect all community values. Eliminating needs-based evaluation for transfers > will foster an environment open to speculation and other artifice used to maximize the monetization of > address resources without providing the benefit to the community of maximizing utilization. The environment open to speculation already exists, a needs-based criteria will not stop the ones that want to speculate. Keeping needs-based criteria in policy will only drive (keep some of the) transfers underground (ie: futures contracts, all kind of financial artifices). I actually believe the needs-based criteria removal will benefit the community by eliminating a barrier in the correct registration of the transfers (resources) in the registry (and whois). The allocation era has passed, ARIN should just be a shepherd and record the transfers (and do the allocation exercise twice per year, when the IANA allocates the few crumbs remaining). From my experience and observations, if someone needs the IP addresses and has the money to pay for them I am sure that they will not be stopped by ARIN's needs-base criteria... > In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the > long run in favor of financial manipulation. I dare to disagree. From where I am standing, the removal of needs-basis criteria from the RIPE Region has increased utilization of the resources transferred through the IPv4 marketplace. Additionally, the removal of the needs-basis criteria has increased the number of transfers, showing that the marketplace works and is useful to hundreds (or even thousands) of companies from the region. I am not saying that the ARIN community should copy what the RIPE community has done. I am just saying that if something is working and it's usability is proven, it is rather strange to see some saying the opposite as an argument against the removal of the needs-based criteria. > > Owen cheers, elvis > >> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >> >> Now that we've reached the magic ZERO in the free pool, what does the community >> think about this new draft policy? >> >> Should ARIN begin the process of streamlining the IPv4 policy so that it is >> geared more toward the transfer market, and remove "need" as a criteria in >> certain sections of the NRPM to increase the database accuracy? >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >> Sent: Wednesday, September 23, 2015 12:54 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> On 17 September 2015 the ARIN Advisory Council (AC) accepted >> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >> >> Draft Policy ARIN-2015-9 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_9.html >> >> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >> >> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (PDP) can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> Date: 23 September 2015 >> >> Problem statement: >> >> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >> Additionally, the 8.1 introduction section includes a perceived "threat" >> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >> >> Policy statement: >> >> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >> >> Section 8.1 Principles: >> >> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >> >> Section 8.2 Mergers and Acquisitions: >> >> - Change the 4th bullet from: >> >> "The resources to be transferred will be subject to ARIN policies." >> >> to: >> >> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >> >> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >> >> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >> >> - Change the first bullet under "Conditions on recipient of the transfer" from: >> >> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >> >> to: >> >> "The recipient must sign an RSA." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" >> from: >> >> "The resources to be transferred will be subject to ARIN policies." >> >> to: >> >> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >> >> Section 8.4 Inter-RIR Transfers to Specified Recipients: >> >> - Change the introductory language from: >> >> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >> >> to: >> >> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" >> from: >> >> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >> >> to: >> >> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >> >> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >> >> Comments: >> >> a. Timetable for implementation: Immediate >> >> b. Anything else >> >> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and >> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >> >> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Thu Sep 24 16:16:13 2015 From: jcurran at arin.net (John Curran) Date: Thu, 24 Sep 2015 20:16:13 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <56045441.2040106@velea.eu> References: <56031167.1010007@arin.net> <12729e54a9ef44a8bddf05036b66c5ab@eni-mail1.eclipse-networks.com> <56045441.2040106@velea.eu> Message-ID: On Sep 24, 2015, at 3:51 PM, Elvis Daniel Velea wrote: > > +1 > > Keeping needs basis in the NRPM will only drive the transfers underground. Some are already using all kind of financial tricks (futures contracts, lease contracts, etc) and are waiting for the needs basis criteria to be removed from NRPM in order to register the transfers in the ARIN Registry. > > The Registry/Whois will win most from the removal of needs basis from the NRPM and process streamlining. Elvis - To be clear, there is nothing ?improper? about a future or option contract if two private parties decide to engage in such (and I can imagine cases where such an arrangement might make sense regardless of state of IPv4 transfer policy.) This does not detract from the your point that the usefulness of the registry is maximum when the party actually using the address block is the registrant (and hence transfer policies which even indirectly encourage other outcomes reduce its functionality, e.g. for operations, etc.) There are even cases where loaning/leasing of address blocks may make sense; I believe your point is that we don?t want to see these sorts of arrangements appear (in circumstances beyond their normal useful roles) as alternatives to transfers simply as a result of transfer policy hurdles - is that correct? Thanks, /John John Curran President and CEO ARIN From owen at delong.com Thu Sep 24 16:37:06 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Sep 2015 13:37:06 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <56045947.9070201@velea.eu> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> Message-ID: <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> Of course your position wouldn?t have anything to do with the profits you stand to make from an unrestricted transfer market. Owen > On Sep 24, 2015, at 13:12 , Elvis Daniel Velea wrote: > > Hi Owen, > > On 24/09/15 22:09, Owen DeLong wrote: >> Short answer: NO >> >> Longer answer: >> >> Finance alone does not reflect all community values. Eliminating needs-based evaluation for transfers >> will foster an environment open to speculation and other artifice used to maximize the monetization of >> address resources without providing the benefit to the community of maximizing utilization. > The environment open to speculation already exists, a needs-based criteria will not stop the ones that want to speculate. Keeping needs-based criteria in policy will only drive (keep some of the) transfers underground (ie: futures contracts, all kind of financial artifices). I actually believe the needs-based criteria removal will benefit the community by eliminating a barrier in the correct registration of the transfers (resources) in the registry (and whois). > > The allocation era has passed, ARIN should just be a shepherd and record the transfers (and do the allocation exercise twice per year, when the IANA allocates the few crumbs remaining). From my experience and observations, if someone needs the IP addresses and has the money to pay for them I am sure that they will not be stopped by ARIN's needs-base criteria... >> In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the >> long run in favor of financial manipulation. > I dare to disagree. From where I am standing, the removal of needs-basis criteria from the RIPE Region has increased utilization of the resources transferred through the IPv4 marketplace. > Additionally, the removal of the needs-basis criteria has increased the number of transfers, showing that the marketplace works and is useful to hundreds (or even thousands) of companies from the region. > > I am not saying that the ARIN community should copy what the RIPE community has done. I am just saying that if something is working and it's usability is proven, it is rather strange to see some saying the opposite as an argument against the removal of the needs-based criteria. >> >> Owen > cheers, > elvis >> >>> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >>> >>> Now that we've reached the magic ZERO in the free pool, what does the community >>> think about this new draft policy? >>> >>> Should ARIN begin the process of streamlining the IPv4 policy so that it is >>> geared more toward the transfer market, and remove "need" as a criteria in >>> certain sections of the NRPM to increase the database accuracy? >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>> Sent: Wednesday, September 23, 2015 12:54 PM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>> >>> Draft Policy ARIN-2015-9 >>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>> >>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>> >>> Draft Policy ARIN-2015-9 is below and can be found at: >>> https://www.arin.net/policy/proposals/2015_9.html >>> >>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >>> >>> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The ARIN Policy Development Process (PDP) can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Communications and Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> Draft Policy ARIN-2015-9 >>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>> >>> Date: 23 September 2015 >>> >>> Problem statement: >>> >>> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >>> Additionally, the 8.1 introduction section includes a perceived "threat" >>> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >>> >>> Policy statement: >>> >>> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >>> >>> Section 8.1 Principles: >>> >>> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >>> >>> Section 8.2 Mergers and Acquisitions: >>> >>> - Change the 4th bullet from: >>> >>> "The resources to be transferred will be subject to ARIN policies." >>> >>> to: >>> >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>> >>> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >>> >>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>> >>> - Change the first bullet under "Conditions on recipient of the transfer" from: >>> >>> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >>> >>> to: >>> >>> "The recipient must sign an RSA." >>> >>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>> from: >>> >>> "The resources to be transferred will be subject to ARIN policies." >>> >>> to: >>> >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>> >>> Section 8.4 Inter-RIR Transfers to Specified Recipients: >>> >>> - Change the introductory language from: >>> >>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >>> >>> to: >>> >>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >>> >>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>> from: >>> >>> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >>> >>> to: >>> >>> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >>> >>> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >>> >>> Comments: >>> >>> a. Timetable for implementation: Immediate >>> >>> b. Anything else >>> >>> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and >>> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >>> >>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From elvis at velea.eu Thu Sep 24 16:52:21 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 24 Sep 2015 23:52:21 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> <12729e54a9ef44a8bddf05036b66c5ab@eni-mail1.eclipse-networks.com> <56045441.2040106@velea.eu> Message-ID: <56046285.1030002@velea.eu> Hi John, On 24/09/15 23:16, John Curran wrote: > On Sep 24, 2015, at 3:51 PM, Elvis Daniel Velea wrote: >> +1 >> >> Keeping needs basis in the NRPM will only drive the transfers underground. Some are already using all kind of financial tricks (futures contracts, lease contracts, etc) and are waiting for the needs basis criteria to be removed from NRPM in order to register the transfers in the ARIN Registry. >> >> The Registry/Whois will win most from the removal of needs basis from the NRPM and process streamlining. > Elvis - > > To be clear, there is nothing ?improper? about a future or option contract if two > private parties decide to engage in such (and I can imagine cases where such > an arrangement might make sense regardless of state of IPv4 transfer policy.) correct. > > This does not detract from the your point that the usefulness of the registry is > maximum when the party actually using the address block is the registrant > (and hence transfer policies which even indirectly encourage other outcomes > reduce its functionality, e.g. for operations, etc.) And I believe that some financial 'tricks' are used instead of just registration in the registry/whois. > > There are even cases where loaning/leasing of address blocks may make sense; that's true.. > I believe your point is that we don?t want to see these sorts of arrangements appear > (in circumstances beyond their normal useful roles) as alternatives to transfers > simply as a result of transfer policy hurdles - is that correct? You got my point. I would rather see needs-based criteria removed in place of having all kind of documents hidden in archives as alternative for the transfer. > > Thanks, > /John > > John Curran > President and CEO > ARIN > regards, elvis From SRyerse at eclipse-networks.com Thu Sep 24 16:53:19 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 24 Sep 2015 20:53:19 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> Message-ID: <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> Many folks make a profit on various Internet services in this Region. ARIN was created to further the Internet and not stifle it. Nowhere do I see that it is part of ARIN's mission to somehow prevent profits via policies. Appears to me to be all about the haves keeping the have nots from obtaining resources. :-( Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Thursday, September 24, 2015 4:37 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Of course your position wouldn?t have anything to do with the profits you stand to make from an unrestricted transfer market. Owen > On Sep 24, 2015, at 13:12 , Elvis Daniel Velea wrote: > > Hi Owen, > > On 24/09/15 22:09, Owen DeLong wrote: >> Short answer: NO >> >> Longer answer: >> >> Finance alone does not reflect all community values. Eliminating >> needs-based evaluation for transfers will foster an environment open >> to speculation and other artifice used to maximize the monetization of address resources without providing the benefit to the community of maximizing utilization. > The environment open to speculation already exists, a needs-based criteria will not stop the ones that want to speculate. Keeping needs-based criteria in policy will only drive (keep some of the) transfers underground (ie: futures contracts, all kind of financial artifices). I actually believe the needs-based criteria removal will benefit the community by eliminating a barrier in the correct registration of the transfers (resources) in the registry (and whois). > > The allocation era has passed, ARIN should just be a shepherd and record the transfers (and do the allocation exercise twice per year, when the IANA allocates the few crumbs remaining). From my experience and observations, if someone needs the IP addresses and has the money to pay for them I am sure that they will not be stopped by ARIN's needs-base criteria... >> In fact, I believe that eliminating needs-basis will likely cause >> actual utilization to be reduced in the long run in favor of financial manipulation. > I dare to disagree. From where I am standing, the removal of needs-basis criteria from the RIPE Region has increased utilization of the resources transferred through the IPv4 marketplace. > Additionally, the removal of the needs-basis criteria has increased the number of transfers, showing that the marketplace works and is useful to hundreds (or even thousands) of companies from the region. > > I am not saying that the ARIN community should copy what the RIPE community has done. I am just saying that if something is working and it's usability is proven, it is rather strange to see some saying the opposite as an argument against the removal of the needs-based criteria. >> >> Owen > cheers, > elvis >> >>> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >>> >>> Now that we've reached the magic ZERO in the free pool, what does >>> the community think about this new draft policy? >>> >>> Should ARIN begin the process of streamlining the IPv4 policy so >>> that it is geared more toward the transfer market, and remove "need" >>> as a criteria in certain sections of the NRPM to increase the database accuracy? >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>> On Behalf Of ARIN >>> Sent: Wednesday, September 23, 2015 12:54 PM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >>> needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of >>> IPv4 netblocks >>> >>> Draft Policy ARIN-2015-9 >>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >>> transfers of IPv4 netblocks >>> >>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>> >>> Draft Policy ARIN-2015-9 is below and can be found at: >>> https://www.arin.net/policy/proposals/2015_9.html >>> >>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >>> >>> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The ARIN Policy Development Process (PDP) can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Communications and Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> Draft Policy ARIN-2015-9 >>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >>> transfers of IPv4 netblocks >>> >>> Date: 23 September 2015 >>> >>> Problem statement: >>> >>> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >>> Additionally, the 8.1 introduction section includes a perceived "threat" >>> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >>> >>> Policy statement: >>> >>> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >>> >>> Section 8.1 Principles: >>> >>> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >>> >>> Section 8.2 Mergers and Acquisitions: >>> >>> - Change the 4th bullet from: >>> >>> "The resources to be transferred will be subject to ARIN policies." >>> >>> to: >>> >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>> >>> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >>> >>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>> >>> - Change the first bullet under "Conditions on recipient of the transfer" from: >>> >>> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >>> >>> to: >>> >>> "The recipient must sign an RSA." >>> >>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>> from: >>> >>> "The resources to be transferred will be subject to ARIN policies." >>> >>> to: >>> >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>> >>> Section 8.4 Inter-RIR Transfers to Specified Recipients: >>> >>> - Change the introductory language from: >>> >>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >>> >>> to: >>> >>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >>> >>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>> from: >>> >>> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >>> >>> to: >>> >>> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >>> >>> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >>> >>> Comments: >>> >>> a. Timetable for implementation: Immediate >>> >>> b. Anything else >>> >>> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, >>> and >>> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >>> >>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the >>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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 matthew at matthew.at Thu Sep 24 17:02:13 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Sep 2015 14:02:13 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> Message-ID: <560464D5.6000208@matthew.at> If you're right, doesn't that simply drive v6 adoption, which is the desired goal? Matthew Kaufman On 9/24/2015 12:09 PM, Owen DeLong wrote: > Short answer: NO > > Longer answer: > > Finance alone does not reflect all community values. Eliminating needs-based evaluation for transfers > will foster an environment open to speculation and other artifice used to maximize the monetization of > address resources without providing the benefit to the community of maximizing utilization. > > In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the > long run in favor of financial manipulation. > > Owen > >> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >> >> Now that we've reached the magic ZERO in the free pool, what does the community >> think about this new draft policy? >> >> Should ARIN begin the process of streamlining the IPv4 policy so that it is >> geared more toward the transfer market, and remove "need" as a criteria in >> certain sections of the NRPM to increase the database accuracy? >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >> Sent: Wednesday, September 23, 2015 12:54 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> On 17 September 2015 the ARIN Advisory Council (AC) accepted >> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >> >> Draft Policy ARIN-2015-9 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_9.html >> >> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >> >> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (PDP) can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> Date: 23 September 2015 >> >> Problem statement: >> >> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >> Additionally, the 8.1 introduction section includes a perceived "threat" >> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >> >> Policy statement: >> >> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >> >> Section 8.1 Principles: >> >> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >> >> Section 8.2 Mergers and Acquisitions: >> >> - Change the 4th bullet from: >> >> "The resources to be transferred will be subject to ARIN policies." >> >> to: >> >> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >> >> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >> >> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >> >> - Change the first bullet under "Conditions on recipient of the transfer" from: >> >> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >> >> to: >> >> "The recipient must sign an RSA." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" >> from: >> >> "The resources to be transferred will be subject to ARIN policies." >> >> to: >> >> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >> >> Section 8.4 Inter-RIR Transfers to Specified Recipients: >> >> - Change the introductory language from: >> >> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >> >> to: >> >> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" >> from: >> >> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >> >> to: >> >> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >> >> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >> >> Comments: >> >> a. Timetable for implementation: Immediate >> >> b. Anything else >> >> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and >> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >> >> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From matthew at matthew.at Thu Sep 24 17:03:20 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Sep 2015 14:03:20 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> Message-ID: <56046518.9040107@matthew.at> Yes. The only lever ARIN has is to penalize people who've made poor choices in the past. If people read the policy, they'll know about the risk of penalty and act accordingly now. I support. Matthew Kaufman On 9/24/2015 12:37 PM, John Springer wrote: > Hi PPML, > > There have been a number of public discussions regarding the ins and > outs of IPV6 subnet allocation. One such starts here: > http://mailman.nanog.org/pipermail/nanog/2014-October/070339.html > > My recollection of the outcomes of these discussions is a sort of > rough consensus that /48 is a good idea and indeed, many of the > calculations used to evaluate what size of V6 block an org should > request, start with that assumtion. > > ARIN (speaking as myself, not a member of any group and roughly > paraphrasing someone more authoritative than I) does not dictate what > you do with addresses after the allocation has been received. In some > cases, ARIN looks at what you do with addresses when you come back for > more and might not give them to you depending on what choices you have > made. > > That is what this Draft Proposal seeks to do. > > I think it is clear that we can do that. Should we? > > And if you have an opinion of no, are you able to say because it is > technically unsound or unfair and partial? > > John Springer > > On Wed, 23 Sep 2015, ARIN wrote: > >> Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> On 17 September 2015 the ARIN Advisory Council (AC) accepted >> "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy. >> >> Draft Policy ARIN-2015-10 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_10.html >> >> You are encouraged to discuss the merits and your concerns of Draft >> Policy 2015-10 on the Public Policy Mailing List. >> >> The AC will evaluate the discussion in order to assess the conformance >> of this draft policy with ARIN's Principles of Internet Number Resource >> Policy as stated in the PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (PDP) can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> Date: 23 September 2015 >> >> Problem Statement: >> >> ISPs may believe that they have an incentive to obtain smaller blocks >> than they really need, and once they receive their allocation may >> subsequently issue blocks smaller than their customers may need in >> the future. This policy seeks to encourage the correct behavior by >> reiterating the smallest reasonable sub-allocation size and by >> discounting any space which has been subdivided more finely from any >> future utilization analysis. >> >> Policy statement: >> >> Modify section 2.15 from "When applied to IPv6 policies, the term >> "provider assignment unit" shall mean the prefix of the smallest >> block a given ISP assigns to end sites (recommended /48)." to "When >> applied to IPv6 policies, the term "provider assignment unit" shall >> mean the prefix of the smallest block a given ISP assigns to end >> sites. A /48 is recommended as this smallest block size. In no case >> shall a provider assignment unit for the purpose of this policy be >> smaller than /56." >> >> Modify section 2.16.1 from "A provider assignment unit shall be >> considered fully utilized when it is assigned to an end-site" to "A >> provider assignment unit shall be considered fully utilized when it >> is assigned in full (or as part of a larger aggregate) to a single >> end-site. If a provider assignment unit (which shall be no smaller >> than /56) is split and assigned to multiple end-sites that entire >> provider assignment unit shall be considered NOT utilized." >> >> Comments: >> 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. >> >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 matthew at matthew.at Thu Sep 24 17:05:46 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Sep 2015 14:05:46 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> Message-ID: <560465AA.2020300@matthew.at> And your position has nothing to do with what you stand to gain as IPv6 becomes more popular and yet IPv4 isn't so constrained as to hamper traffic growth. Why don't we instead completely refrain from allegations of wrongdoing with regard to one's opinions about the policies? Matthew Kaufman On 9/24/2015 1:37 PM, Owen DeLong wrote: > Of course your position wouldn?t have anything to do with the profits you stand to make from an unrestricted transfer market. > > Owen > >> On Sep 24, 2015, at 13:12 , Elvis Daniel Velea wrote: >> >> Hi Owen, >> >> On 24/09/15 22:09, Owen DeLong wrote: >>> Short answer: NO >>> >>> Longer answer: >>> >>> Finance alone does not reflect all community values. Eliminating needs-based evaluation for transfers >>> will foster an environment open to speculation and other artifice used to maximize the monetization of >>> address resources without providing the benefit to the community of maximizing utilization. >> The environment open to speculation already exists, a needs-based criteria will not stop the ones that want to speculate. Keeping needs-based criteria in policy will only drive (keep some of the) transfers underground (ie: futures contracts, all kind of financial artifices). I actually believe the needs-based criteria removal will benefit the community by eliminating a barrier in the correct registration of the transfers (resources) in the registry (and whois). >> >> The allocation era has passed, ARIN should just be a shepherd and record the transfers (and do the allocation exercise twice per year, when the IANA allocates the few crumbs remaining). From my experience and observations, if someone needs the IP addresses and has the money to pay for them I am sure that they will not be stopped by ARIN's needs-base criteria... >>> In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the >>> long run in favor of financial manipulation. >> I dare to disagree. From where I am standing, the removal of needs-basis criteria from the RIPE Region has increased utilization of the resources transferred through the IPv4 marketplace. >> Additionally, the removal of the needs-basis criteria has increased the number of transfers, showing that the marketplace works and is useful to hundreds (or even thousands) of companies from the region. >> >> I am not saying that the ARIN community should copy what the RIPE community has done. I am just saying that if something is working and it's usability is proven, it is rather strange to see some saying the opposite as an argument against the removal of the needs-based criteria. >>> Owen >> cheers, >> elvis >>>> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >>>> >>>> Now that we've reached the magic ZERO in the free pool, what does the community >>>> think about this new draft policy? >>>> >>>> Should ARIN begin the process of streamlining the IPv4 policy so that it is >>>> geared more toward the transfer market, and remove "need" as a criteria in >>>> certain sections of the NRPM to increase the database accuracy? >>>> >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>>> Sent: Wednesday, September 23, 2015 12:54 PM >>>> To: arin-ppml at arin.net >>>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> Draft Policy ARIN-2015-9 >>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>>> >>>> Draft Policy ARIN-2015-9 is below and can be found at: >>>> https://www.arin.net/policy/proposals/2015_9.html >>>> >>>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >>>> >>>> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >>>> >>>> * Enabling Fair and Impartial Number Resource Administration >>>> * Technically Sound >>>> * Supported by the Community >>>> >>>> The ARIN Policy Development Process (PDP) can be found at: >>>> https://www.arin.net/policy/pdp.html >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> Regards, >>>> >>>> Communications and Member Services >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> ## * ## >>>> >>>> Draft Policy ARIN-2015-9 >>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> Date: 23 September 2015 >>>> >>>> Problem statement: >>>> >>>> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >>>> Additionally, the 8.1 introduction section includes a perceived "threat" >>>> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >>>> >>>> Policy statement: >>>> >>>> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >>>> >>>> Section 8.1 Principles: >>>> >>>> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >>>> >>>> Section 8.2 Mergers and Acquisitions: >>>> >>>> - Change the 4th bullet from: >>>> >>>> "The resources to be transferred will be subject to ARIN policies." >>>> >>>> to: >>>> >>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>> >>>> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >>>> >>>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>>> >>>> - Change the first bullet under "Conditions on recipient of the transfer" from: >>>> >>>> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >>>> >>>> to: >>>> >>>> "The recipient must sign an RSA." >>>> >>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>> from: >>>> >>>> "The resources to be transferred will be subject to ARIN policies." >>>> >>>> to: >>>> >>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>> >>>> Section 8.4 Inter-RIR Transfers to Specified Recipients: >>>> >>>> - Change the introductory language from: >>>> >>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >>>> >>>> to: >>>> >>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >>>> >>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>> from: >>>> >>>> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >>>> >>>> to: >>>> >>>> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >>>> >>>> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >>>> >>>> Comments: >>>> >>>> a. Timetable for implementation: Immediate >>>> >>>> b. Anything else >>>> >>>> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and >>>> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >>>> >>>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 elvis at velea.eu Thu Sep 24 17:11:38 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 25 Sep 2015 00:11:38 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> Message-ID: <5604670A.2090508@velea.eu> Owen, if someone needs an IPv4 transfer and wants to use our brokerage firm, believe me we will be happy to assist them and help them get what they need (regardless of whether the needs-based criteria is still in the policy or not). Off course, we will do everything to respect the policies of (all of) the RIRs while helping our customers get what they want. An unrestricted transfer market may increase the number of transfers we broker - that's true, but in the end 'the money' (you call it profits) will be the same. The number of available (read: unused and ready to be transferred) IP addresses will not change, we (the brokers) will broker them regardless of who the buyer is. What will change is the correct registration (in place of the contracts hidden in a drawer in a lawyer's office). There is almost a /12 unmet (read: justified) on the ARIN waiting list.. in 2.5 months. We won't probably be able to keep up with the number of companies receiving approvals from ARIN, so.. no I have worries about our 'profits'. What I worry about is that, maybe, those that have the funds will buy the resources and not keep a proper registration because either the policy is too restrictive to them, their employee has not succeeded in convincing the ARIN staff or their future usage plans were maybe not clear enough. Again, from my experience (we've brokered more than a /11 in the 2 years since our company exists) if someone has the money for it and wants it, they will get it . regards, elvis On 24/09/15 23:37, Owen DeLong wrote: > Of course your position wouldn?t have anything to do with the profits you stand to make from an unrestricted transfer market. > > Owen > >> On Sep 24, 2015, at 13:12 , Elvis Daniel Velea wrote: >> >> Hi Owen, >> >> On 24/09/15 22:09, Owen DeLong wrote: >>> Short answer: NO >>> >>> Longer answer: >>> >>> Finance alone does not reflect all community values. Eliminating needs-based evaluation for transfers >>> will foster an environment open to speculation and other artifice used to maximize the monetization of >>> address resources without providing the benefit to the community of maximizing utilization. >> The environment open to speculation already exists, a needs-based criteria will not stop the ones that want to speculate. Keeping needs-based criteria in policy will only drive (keep some of the) transfers underground (ie: futures contracts, all kind of financial artifices). I actually believe the needs-based criteria removal will benefit the community by eliminating a barrier in the correct registration of the transfers (resources) in the registry (and whois). >> >> The allocation era has passed, ARIN should just be a shepherd and record the transfers (and do the allocation exercise twice per year, when the IANA allocates the few crumbs remaining). From my experience and observations, if someone needs the IP addresses and has the money to pay for them I am sure that they will not be stopped by ARIN's needs-base criteria... >>> In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the >>> long run in favor of financial manipulation. >> I dare to disagree. From where I am standing, the removal of needs-basis criteria from the RIPE Region has increased utilization of the resources transferred through the IPv4 marketplace. >> Additionally, the removal of the needs-basis criteria has increased the number of transfers, showing that the marketplace works and is useful to hundreds (or even thousands) of companies from the region. >> >> I am not saying that the ARIN community should copy what the RIPE community has done. I am just saying that if something is working and it's usability is proven, it is rather strange to see some saying the opposite as an argument against the removal of the needs-based criteria. >>> Owen >> cheers, >> elvis >>>> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >>>> >>>> Now that we've reached the magic ZERO in the free pool, what does the community >>>> think about this new draft policy? >>>> >>>> Should ARIN begin the process of streamlining the IPv4 policy so that it is >>>> geared more toward the transfer market, and remove "need" as a criteria in >>>> certain sections of the NRPM to increase the database accuracy? >>>> >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>>> Sent: Wednesday, September 23, 2015 12:54 PM >>>> To: arin-ppml at arin.net >>>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> Draft Policy ARIN-2015-9 >>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>>> >>>> Draft Policy ARIN-2015-9 is below and can be found at: >>>> https://www.arin.net/policy/proposals/2015_9.html >>>> >>>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >>>> >>>> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >>>> >>>> * Enabling Fair and Impartial Number Resource Administration >>>> * Technically Sound >>>> * Supported by the Community >>>> >>>> The ARIN Policy Development Process (PDP) can be found at: >>>> https://www.arin.net/policy/pdp.html >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> Regards, >>>> >>>> Communications and Member Services >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> ## * ## >>>> >>>> Draft Policy ARIN-2015-9 >>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> Date: 23 September 2015 >>>> >>>> Problem statement: >>>> >>>> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >>>> Additionally, the 8.1 introduction section includes a perceived "threat" >>>> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >>>> >>>> Policy statement: >>>> >>>> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >>>> >>>> Section 8.1 Principles: >>>> >>>> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >>>> >>>> Section 8.2 Mergers and Acquisitions: >>>> >>>> - Change the 4th bullet from: >>>> >>>> "The resources to be transferred will be subject to ARIN policies." >>>> >>>> to: >>>> >>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>> >>>> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >>>> >>>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>>> >>>> - Change the first bullet under "Conditions on recipient of the transfer" from: >>>> >>>> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >>>> >>>> to: >>>> >>>> "The recipient must sign an RSA." >>>> >>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>> from: >>>> >>>> "The resources to be transferred will be subject to ARIN policies." >>>> >>>> to: >>>> >>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>> >>>> Section 8.4 Inter-RIR Transfers to Specified Recipients: >>>> >>>> - Change the introductory language from: >>>> >>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >>>> >>>> to: >>>> >>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >>>> >>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>> from: >>>> >>>> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >>>> >>>> to: >>>> >>>> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >>>> >>>> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >>>> >>>> Comments: >>>> >>>> a. Timetable for implementation: Immediate >>>> >>>> b. Anything else >>>> >>>> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and >>>> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >>>> >>>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. From rbf+arin-ppml at panix.com Thu Sep 24 18:36:17 2015 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Thu, 24 Sep 2015 17:36:17 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <56045441.2040106@velea.eu> References: <56031167.1010007@arin.net> <12729e54a9ef44a8bddf05036b66c5ab@eni-mail1.eclipse-networks.com> <56045441.2040106@velea.eu> Message-ID: <20150924223617.GA24394@panix.com> On Thu, Sep 24, 2015 at 10:51:29PM +0300, Elvis Daniel Velea wrote: > +1 > > Keeping needs basis in the NRPM will only drive the transfers underground. > Some are already using all kind of financial tricks (futures contracts, > lease contracts, etc) and are waiting for the needs basis criteria to be > removed from NRPM in order to register the transfers in the ARIN Registry. Requiring that the transfer be handled completely underground adds risk and cost to a transaction that would be less risky and less expensive if it could be handled completely above board and recorded in ARIN's records. That additional cost and risk will cause some people who can't justify their need (as defined in ARIN policies) to forgo an underground transfer. And that will have the effect of reducing the volume of non-needs-based transfers. So it's not true that the *only* effect of the needs basis is to drive transfers underground. It does that with some transfers; it also prevents some transfers. Some people might rationally believe that that's a benefit, and enough of a benefit to offset the costs of having IP addresses in defacto use by parties other than those listed in the ARIN database. (I'm not agreeing with that position; just commenting on it's existence.) What's more interesting is that the speculative transfers are possibly the ones least impacted by forcing them underground. If I want to acquire IP addresses today to use on my operational network tomorrow (but in a manner that won't meet ARIN's criteria for justified need), there's risk to me doing an underground transaction, because it increases the difficultly associated with getting the IP address space that I acquire routed on the public Internet, and with resolving issues should someone else announce the space. On the other hand, if I want to acquire IP addresses today, for the purpose of reselling them for a higher price at some point in the future, there's much less reason for me to be concerned about an underground transfer. I contract for the right to direct the current owner to transfer them as I see fit (and to direct the current owner to not route them on the public Internet -- to make sure he doesn't reputationally damage them), and then I wait until the price goes up to the point where I want to sell. At that point, I find a buyer who can satisfy ARIN's needs-based jutification, and I direct that the addresses be transferred to him. He has no trouble routing them on the public Internet because it's an ARIN-recognized transfer. I got to engage in my intended speculation (and the IP addresses remained idle, because the original (and ARIN-recognized) holder of the space couldn't use them or transfer them, because he was contractually prohibited from doing so). Obviously, the inability to register the initial transaction with ARIN creates some risk. For example, the original holder could "sell" his addresses multiple times, and the buyers only resources would be to sue him when the duplicity was discovered; by then, he might have made himself judgement proof. Certainly the multiple-sale case is also possible with an underground transfer to a recipient who uses the addresses on the public Internet immediately, but it's harder to sell addresses a second time when the first buyer is currently routing them on the public Internet. Still, the point stands that the burden imposed by needs-based policies is at least arguably higher on buyers that want to use the addresses now is higher than the burden imposed on speculators. > The Registry/Whois will win most from the removal of needs basis from the > NRPM and process streamlining. -- Brett From springer at inlandnet.com Thu Sep 24 18:41:28 2015 From: springer at inlandnet.com (John Springer) Date: Thu, 24 Sep 2015 15:41:28 -0700 (PDT) Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <29286955-3FFD-417B-98D5-B44A5183DB7D@delong.com> References: <56031175.5040102@arin.net> <29286955-3FFD-417B-98D5-B44A5183DB7D@delong.com> Message-ID: Hi Owen, On Thu, 24 Sep 2015, Owen DeLong wrote: > >> On Sep 24, 2015, at 12:37 , John Springer wrote: >> >> And if you have an opinion of no, are you able to say because it is technically unsound or unfair and partial? > > This isn?t really necessary, John. A proposal must be fair, technically sound, and have support of the community in order to be adopted. > > Just because it is technically sound and/or fair does not mean that the community must support it. > > People are free to reject a policy for any reason, though I admit a bias in favor of at least some rationale for rejection. > > Owen > Oh, I think it is necessary for the community to comment on all three criteria, Owen, and I thank you for inviting them to express support or opposition. BTW, do you support or oppose the Draft Policy? John Springer From rudi.daniel at gmail.com Thu Sep 24 19:17:37 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 24 Sep 2015 19:17:37 -0400 Subject: [arin-ppml] ARIN-PPML 2015-6 Message-ID: "In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the long run in favor of financial manipulation....Owen" Until Proven otherwise, I am inclined to support Owen's view on this. I think adoption of 2015-6 is likely to legitimize the monetization of ip addresses, leading to a complex market structure dominated by certain sections of the business community, whilst possibly delaying the adoption of Ipv6 and slowing innovation. The main artery of purpose seems to hang on the need to maintain an accurate whois, driving RIR s to refocus purely on registration...this sounds like a free for all, and so far I am not convinced that that is in the interest of the community as a whole, and may result in the IP wars. "1. has been an ARIN customer for at least 36 months; AND 2. is currently in good standing with ARIN; AND 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND 4. can demonstrate it has a meaningful business that operates in the ARIN region." Not sure what a "meaningful business" is. The staff has also indicated some technical issues and cost implications. Is the proposer seriously suggesting that the increased registrations and what may be a ghostly expectation of an even more accurate whois will more than cover the increased cost of implementing 2015-6? What does the proposer believe is most likely to happen in the short to medium term were this draft policy not be supported by the community and what would be the likely impact on ARIN operations, staff, technical, legal; of what the proposer is trying to avoid? There maybe a need to do something, but, my thoughts lean towards a global policy, across all RIRs. RD On Sep 24, 2015 3:10 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2015-6: Transfers and Multi-national > Networks - revised (ARIN) > 2. Re: Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 > netblocks (Leif Sawyer) > 3. Re: Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 > netblocks (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Sep 2015 17:12:13 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-6: Transfers and > Multi-national Networks - revised > Message-ID: <560315AD.5000209 at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 1 September 2015 the ARIN Advisory Council revised 2015-6. Below you > will find the the updated ARIN staff assessment. > > ARIN-2015-5 is below and can be found at: > https://www.arin.net/policy/proposals/2015_5.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN STAFF & LEGAL ASSESSMENT > Draft Policy ARIN-2015-6 > TRANSFERS AND MULTI-NATIONAL NETWORKS > > Date of Assessment: 15 September 2015 > > ___ > 1. Summary (Staff Understanding) > > This proposal states that when evaluating transfer requests, ARIN will > not consider the geographic location where an organization is utilizing, > or will utilize, its ARIN-registered addresses if that organization, its > parent, or a subsidiary are able to satisfy each of the four stated > criteria. > > ___ > 2. Comments > > A. ARIN Staff Comments > > ? During the course of a transfer request, staff will consider and > review the utilization of any block issued by ARIN to that organization, > regardless of whether that address space is being used outside of the > ARIN region. > ? This policy enables organizations to qualify as a recipient for 8.3 or > 8.4 transfers in the ARIN region when they might not have otherwise been > able to do so. ARIN staff would now be able to consider their global > utilization, instead of only their in-ARIN region use. > ? One of the elements ARIN staff uses to determine 24-month need for an > organization is their historical utilization rate. This proposal allows > organizations to justify a larger 24-month needs based qualification, > because staff will consider their utilization globally instead of just > what was used inside the ARIN region. > ? This would be placed in a new section of the NRPM called "8.5 > Additional Transfer Policies". > ? This policy could be implemented as written. > > B. ARIN General Counsel ? Legal Assessment > > No material legal issues. If the policy is enacted it will require ARIN > staff to work with counsel with some attendant increase in costs in the > first year to manage implementation. > > ___ > 3. Resource Impact > > From a request review standpoint, implementation of this policy would > have minimal resource impact. However, it could have future staffing > implications based on the amount of additional work the policy could > present. It is estimated that implementation could occur within 3 months > after ratification by the ARIN Board of Trustees. The following would be > needed in order to implement: > > * Updated guidelines and internal procedures > * Staff training > > Implementation of this policy may allow for registrations in the ARIN > database that require unicode character sets. From an engineering > standpoint, implementation of this policy could have a major resource > impact. It is estimated that implementation would occur within 12 > months, instead of the 3 months cited above, after ratification by the > ARIN Board of Trustees if ARIN is required to support unicode character > sets. The following would be needed in order to implement: > > * Engineering: Engineering efforts to handle out of region business > rules may be substantial as our system only supports ascii now. If there > is a need for unicode character sets, then there is a substantial amount > of work required to upgrade the DB and applications to support unicode. > Additionally, we would need to discuss how to display unicode characters > in port 43 whois. > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2015-6 > > Problem statement: > > Some organizations within the ARIN region are currently unable to > receive IPv4 space via transfer based on current ARIN policy, which > prohibits address space used outside of the ARIN region from being > considered efficiently utilized. This proposal would allow organizations > with a strong and long-standing presence in the ARIN region to be able > to receive number resources via transfer for their global operations. > > Policy statement: > > When evaluating transfer requests, ARIN will not consider the geographic > location where an organization is utilizing, or will utilize, its > ARIN-registered addresses if that organization, its parent, or a > subsidiary: > > 1. has been an ARIN customer for at least 36 months; AND > 2. is currently in good standing with ARIN; AND > 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND > 4. can demonstrate it has a meaningful business that operates in the > ARIN region. > > > > On 9/1/15 1:01 PM, ARIN wrote: > > ARIN-2015-6 has been revised. > > > > You are encouraged to discuss the merits and your concerns of Draft > > Policy 2015-6 on the Public Policy Mailing List. > > > > The AC will evaluate the discussion in order to assess the conformance > > of this draft policy with ARIN's Principles of Internet Number Resource > > Policy as stated in the PDP. Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > ARIN-2015-6 is below and can be found at: > > https://www.arin.net/policy/proposals/2015_6.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Draft Policy ARIN-2015-6 > > Transfers and Multi-national Networks > > > > Date: 25 August 2015 > > > > Problem statement: > > > > Some organizations within the ARIN region are currently unable to > > receive IPv4 space via transfer based on current ARIN policy, which > > prohibits address space used outside of the ARIN region from being > > considered efficiently utilized. This proposal would allow organizations > > with a strong and long-standing presence in the ARIN region to be able > > to receive number resources via transfer for their global operations. > > > > Policy statement: > > > > When evaluating transfer requests, ARIN will not consider the geographic > > location where an organization is utilizing, or will utilize, its > > ARIN-registered addresses if that organization, its parent, or a > > subsidiary: > > > > 1. has been an ARIN customer for at least 36 months; AND > > > > 2. is currently in good standing with ARIN; AND > > > > 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND > > > > 4. can demonstrate it has a meaningful business that operates in the > > ARIN region. > > > > Comments: > > > > Timetable for implementation: Immediate > > > > ##### > > > > ARIN STAFF & LEGAL ASSESSMENT > > > > Draft Policy ARIN-2015-6 > > TRANSFERS AND MULTI-NATIONAL NETWORKS > > https://www.arin.net/policy/proposals/2015_6.html > > > > Date of Assessment: 18 August 2015 > > > > ___ > > 1. Summary (Staff Understanding) > > > > This proposal states that when evaluating transfer requests, ARIN will > > not consider the geographic location where an organization is utilizing > > its ARIN-registered addresses if that organization, its parent, or a > > subsidiary are able to satisfy each of the four stated criteria. > > > > ___ > > 2. Comments > > > > A. ARIN Staff Comments > > > > ?During the course of a transfer request, staff will consider and review > > the utilization of any block issued by ARIN to that organization, > > regardless of whether that address space is being used outside of the > > ARIN region. > > ?This policy enables organizations to qualify as a recipient for 8.3 or > > 8.4 transfers in the ARIN region when they might not have otherwise been > > able to do so. ARIN staff would now be able to consider their global > > utilization, instead of only their in-ARIN region use. > > ?One of the elements ARIN staff uses to determine 24-month need for an > > organization is their historical utilization rate. This proposal allows > > organizations to justify a larger 24-month needs based qualification, > > because staff will consider their utilization globally instead of just > > what was used inside the ARIN region. > > ?The policy proposal text appears to not align with the intent of the > > policy as described in the problem statement. This proposal changes how > > ARIN considers prior utilization of IPv4 address space, but does not > > specify that newly received resources can be used outside of the region. > > Existing policy and practice would dictate ARIN continues to issue space > > for use in the ARIN region. We note that 2015-5, if adopted, could > > change this. > > ?This would be placed in a new section of the NRPM called "8.5 > > Additional Transfer Policies". > > ?This policy could be implemented as written. > > > > B. ARIN General Counsel ? Legal Assessment > > > > No material legal issues. If the policy is enacted it will require ARIN > > staff to work with counsel with some attendant increase in costs in the > > first year to manage implementation. > > > > ___ > > 3. Resource Impact > > This policy would have minimal resource impact from an implementation > > aspect. However, it could have future staffing implications based on the > > amount of additional work the policy could present. 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: > > > > * Updated guidelines and internal procedures > > * Staff training > > > > ___ > > 4. Proposal / Draft Policy Text Assessed > > > > Draft Policy ARIN-2015-6 > > > > Date: 23 June 2015 > > > > Problem statement: > > Some organizations within the ARIN region are currently unable to > > receive IPv4 space via transfer based on current ARIN policy, which > > prohibits address space used outside of the ARIN region from being > > considered efficiently utilized. This proposal would allow organizations > > with a strong and long-standing presence in the ARIN region to be able > > to receive number resources via transfer for their global operations. > > Policy statement: > > When evaluating transfer requests, ARIN will not consider the geographic > > location where an organization is utilizing its ARIN-registered > > addresses if that organization, its parent, or a subsidiary: > > 1. has been an ARIN customer for at least 36 months; AND > > 2. is currently in good standing with ARIN; AND > > 3. is currently using IPv4 or IPv6 addresses in the ARIN region; AND > > 4. can demonstrate it has a meaningful business that operates in the > > ARIN region. > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 24 Sep 2015 18:55:26 +0000 > From: Leif Sawyer > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of > IPv4 > netblocks > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Now that we've reached the magic ZERO in the free pool, what does the > community > think about this new draft policy? > > Should ARIN begin the process of streamlining the IPv4 policy so that it is > geared more toward the transfer market, and remove "need" as a criteria in > certain sections of the NRPM to increase the database accuracy? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Wednesday, September 23, 2015 12:54 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers > of IPv4 netblocks > > On 17 September 2015 the ARIN Advisory Council (AC) accepted > "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > > Draft Policy ARIN-2015-9 is below and can be found at: > https://www.arin.net/policy/proposals/2015_9.html > > You are encouraged to discuss the merits and your concerns of Draft Policy > 2015-9 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance of > this draft policy with ARIN's Principles of Internet Number Resource Policy > as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers > of IPv4 netblocks > > Date: 23 September 2015 > > Problem statement: > > The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer > of IPv4 netblocks from one organization to another are currently a > hindrance in ensuring database accuracy. In practice, ARIN staff are > utilizing those polices to refuse to complete database updates which would > reflect an accurate transfer of control / utilization of netblocks in cases > where ARIN doesn't agree that the recipient organization has need, or more > often where the recipient organization bypasses the ARIN registry entirely > in order to secure the needed IPv4 netblocks in a more timely fashion > directly from the current holder. > Additionally, the 8.1 introduction section includes a perceived "threat" > of reclaim which serves as a hindrance to long-term resource holders > approaching ARIN with database updates when transferring resources. The > result is that the data visible in ARIN registry continues to become more > inaccurate over time. > > Policy statement: > > This proposal is for the following language changes in the respective NRPM > sections in order to eliminate all needs-based evaluation for the > respective transfer type, and allow transfers to be reflected in the > database as they occur following an agreement of transfer from the resource > provider to the recipient. > > Section 8.1 Principles: > > - Strike the 3rd paragraph which begins with "Number resources are issued, > based on justified need, to organizations. . ." since it mostly reiterates > other sections of ARIN policy. All transfers are subjected to those > policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this > paragraph removes the perceived "threat" of reclaim which serves as a > hindrance to long-term resource holders approaching ARIN with database > updates, since in practice ARIN has not been forcibly reclaiming IP > resources assigned to "failed businesses." > > Section 8.2 Mergers and Acquisitions: > > - Change the 4th bullet from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification or inspection > of current or future utilization rate." > > - Remove entirely the last paragraph which reads "In the event that number > resources of the combined organizations are no longer justified under ARIN > policy at the time ARIN becomes aware of the transaction, through a > transfer request or otherwise, ARIN will work with the resource holder(s) > to return or transfer resources as needed to restore compliance via the > processes outlined in current ARIN policy." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > > - Change the first bullet under "Conditions on recipient of the transfer" > from: > > "The recipient must demonstrate the need for up to a 24-month supply of IP > address resources under current ARIN policies and sign an RSA." > > to: > > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification or inspection > of current or future utilization rate." > > Section 8.4 Inter-RIR Transfers to Specified Recipients: > > - Change the introductory language from: > > "Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, needs-based policies." > > to: > > "Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, policies." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > from: > > "Recipients within the ARIN region will be subject to current ARIN > policies and sign an RSA for the resources being received." > > to: > > "Recipients within the ARIN region will be subject to current ARIN > policies, excluding any policies related to needs-based justification or > inspection of current or future utilization rate, and sign an RSA for the > resources being received." > > - Remove entirely the 3rd bullet under "Conditions on recipient of the > transfer" which reads "Recipients within the ARIN region must demonstrate > the need for up to a 24-month supply of IPv4 address space." > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and > ARIN) has now been exhausted, networks in need of additional IPv4 > addresses have shifted away from the practice of receiving them from the > RIR's resource pool. Instead, networks in need are seeking out current > holders of IPv4 resources who are willing to transfer them in order to > fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis > IPv4 netblock governance has shifted from "allocation" to "documentation." > In other words, the focus must move away from practicing conservation and > fair distribution (e.g. following guidelines set forth in RFC2050) to > ensuring an accurate registry database of which organization is utilizing a > given netblock as a result of transfers which occur between organizations. > > The RIPE registry can be used as a reference of one which has evolved over > the past couple years to shift their focus away from > conservation/allocation and towards database accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. Provided the organizations meet the basic > requirement of RIR membership, and that the transferring organization has > the valid authority to request the transfer, the transaction completes > without any "needs-based" review. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > ------------------------------ > > Message: 3 > Date: Thu, 24 Sep 2015 12:09:31 -0700 > From: Owen DeLong > To: Leif Sawyer > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers > of IPv4 > netblocks > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Short answer: NO > > Longer answer: > > Finance alone does not reflect all community values. Eliminating > needs-based evaluation for transfers > will foster an environment open to speculation and other artifice used to > maximize the monetization of > address resources without providing the benefit to the community of > maximizing utilization. > > In fact, I believe that eliminating needs-basis will likely cause actual > utilization to be reduced in the > long run in favor of financial manipulation. > > Owen > > > On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: > > > > Now that we've reached the magic ZERO in the free pool, what does the > community > > think about this new draft policy? > > > > Should ARIN begin the process of streamlining the IPv4 policy so that it > is > > geared more toward the transfer market, and remove "need" as a criteria > in > > certain sections of the NRPM to increase the database accuracy? > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > > Sent: Wednesday, September 23, 2015 12:54 PM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > > Draft Policy ARIN-2015-9 > > Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > transfers of IPv4 netblocks > > > > On 17 September 2015 the ARIN Advisory Council (AC) accepted > > "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > > > > Draft Policy ARIN-2015-9 is below and can be found at: > > https://www.arin.net/policy/proposals/2015_9.html > > > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-9 on the Public Policy Mailing List. > > > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The ARIN Policy Development Process (PDP) can be found at: > > https://www.arin.net/policy/pdp.html > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > Draft Policy ARIN-2015-9 > > Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > transfers of IPv4 netblocks > > > > Date: 23 September 2015 > > > > Problem statement: > > > > The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding > transfer of IPv4 netblocks from one organization to another are currently a > hindrance in ensuring database accuracy. In practice, ARIN staff are > utilizing those polices to refuse to complete database updates which would > reflect an accurate transfer of control / utilization of netblocks in cases > where ARIN doesn't agree that the recipient organization has need, or more > often where the recipient organization bypasses the ARIN registry entirely > in order to secure the needed IPv4 netblocks in a more timely fashion > directly from the current holder. > > Additionally, the 8.1 introduction section includes a perceived "threat" > > of reclaim which serves as a hindrance to long-term resource holders > approaching ARIN with database updates when transferring resources. The > result is that the data visible in ARIN registry continues to become more > inaccurate over time. > > > > Policy statement: > > > > This proposal is for the following language changes in the respective > NRPM sections in order to eliminate all needs-based evaluation for the > respective transfer type, and allow transfers to be reflected in the > database as they occur following an agreement of transfer from the resource > provider to the recipient. > > > > Section 8.1 Principles: > > > > - Strike the 3rd paragraph which begins with "Number resources are > issued, based on justified need, to organizations. . ." since it mostly > reiterates other sections of ARIN policy. All transfers are subjected to > those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this > paragraph removes the perceived "threat" of reclaim which serves as a > hindrance to long-term resource holders approaching ARIN with database > updates, since in practice ARIN has not been forcibly reclaiming IP > resources assigned to "failed businesses." > > > > Section 8.2 Mergers and Acquisitions: > > > > - Change the 4th bullet from: > > > > "The resources to be transferred will be subject to ARIN policies." > > > > to: > > > > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification or inspection > of current or future utilization rate." > > > > - Remove entirely the last paragraph which reads "In the event that > number resources of the combined organizations are no longer justified > under ARIN policy at the time ARIN becomes aware of the transaction, > through a transfer request or otherwise, ARIN will work with the resource > holder(s) to return or transfer resources as needed to restore compliance > via the processes outlined in current ARIN policy." > > > > Section 8.3 Transfers between Specified Recipients within the ARIN > Region: > > > > - Change the first bullet under "Conditions on recipient of the > transfer" from: > > > > "The recipient must demonstrate the need for up to a 24-month supply of > IP address resources under current ARIN policies and sign an RSA." > > > > to: > > > > "The recipient must sign an RSA." > > > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > > from: > > > > "The resources to be transferred will be subject to ARIN policies." > > > > to: > > > > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification or inspection > of current or future utilization rate." > > > > Section 8.4 Inter-RIR Transfers to Specified Recipients: > > > > - Change the introductory language from: > > > > "Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, needs-based policies." > > > > to: > > > > "Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, policies." > > > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > > from: > > > > "Recipients within the ARIN region will be subject to current ARIN > policies and sign an RSA for the resources being received." > > > > to: > > > > "Recipients within the ARIN region will be subject to current ARIN > policies, excluding any policies related to needs-based justification or > inspection of current or future utilization rate, and sign an RSA for the > resources being received." > > > > - Remove entirely the 3rd bullet under "Conditions on recipient of the > transfer" which reads "Recipients within the ARIN region must demonstrate > the need for up to a 24-month supply of IPv4 address space." > > > > Comments: > > > > a. Timetable for implementation: Immediate > > > > b. Anything else > > > > As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and > > ARIN) has now been exhausted, networks in need of additional IPv4 > addresses have shifted away from the practice of receiving them from the > RIR's resource pool. Instead, networks in need are seeking out current > holders of IPv4 resources who are willing to transfer them in order to > fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis > IPv4 netblock governance has shifted from "allocation" to "documentation." > In other words, the focus must move away from practicing conservation and > fair distribution (e.g. following guidelines set forth in RFC2050) to > ensuring an accurate registry database of which organization is utilizing a > given netblock as a result of transfers which occur between organizations. > > > > The RIPE registry can be used as a reference of one which has evolved > over the past couple years to shift their focus away from > conservation/allocation and towards database accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. Provided the organizations meet the basic > requirement of RIR membership, and that the transferring organization has > the valid authority to request the transfer, the transaction completes > without any "needs-based" review. > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 123, Issue 16 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From droisman at softlayer.com Thu Sep 24 21:20:49 2015 From: droisman at softlayer.com (Dani Roisman) Date: Fri, 25 Sep 2015 01:20:49 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Message-ID: | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman From rjletts at uw.edu Thu Sep 24 23:46:42 2015 From: rjletts at uw.edu (Richard J. Letts) Date: Fri, 25 Sep 2015 03:46:42 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. Richard ________________________________________ From: arin-ppml-bounces at arin.net on behalf of Dani Roisman Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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 narten at us.ibm.com Fri Sep 25 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 25 Sep 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201509250453.t8P4r2F9028872@rotala.raleigh.ibm.com> Total of 29 messages in the last 7 days. script run at: Fri Sep 25 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.69% | 6 | 19.80% | 81130 | info at arin.net 13.79% | 4 | 13.14% | 53861 | elvis at velea.eu 3.45% | 1 | 19.12% | 78362 | rudi.daniel at gmail.com 10.34% | 3 | 10.36% | 42436 | matthew at matthew.at 10.34% | 3 | 10.04% | 41128 | owen at delong.com 6.90% | 2 | 6.97% | 28567 | sryerse at eclipse-networks.com 6.90% | 2 | 3.71% | 15221 | springer at inlandnet.com 3.45% | 1 | 3.27% | 13384 | lsawyer at gci.com 3.45% | 1 | 2.99% | 12259 | rjletts at uw.edu 3.45% | 1 | 2.14% | 8780 | rbf+arin-ppml at panix.com 3.45% | 1 | 1.80% | 7385 | narten at us.ibm.com 3.45% | 1 | 1.80% | 7376 | droisman at softlayer.com 3.45% | 1 | 1.73% | 7084 | jcurran at arin.net 3.45% | 1 | 1.71% | 7027 | bill at herrin.us 3.45% | 1 | 1.41% | 5792 | mike at iptrading.com --------+------+--------+----------+------------------------ 100.00% | 29 |100.00% | 409792 | Total From owen at delong.com Fri Sep 25 02:23:46 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Sep 2015 23:23:46 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> Message-ID: <0742D43D-F93C-40EF-AAB0-7B061DE1E9C1@delong.com> It?s not ARIN?s mission to prevent profits nor did I say it was. My point is that Elvis support for removing policy is strongly influenced by the potential windfall he stands to reap while not actually providing any internet services in the process if the policy is changed as he wishes. As yo pointed out, many folks make a profit on various INETERNET SERVICES. Elvis, OTOH is not in the internet services business. He?s strictly an address broker. It would be sort of like Realtors arguing against transfer taxes on real estate. An argument based solely in greed rather than any actual concern for the common good. Owen > On Sep 24, 2015, at 13:53 , Steven Ryerse wrote: > > Many folks make a profit on various Internet services in this Region. ARIN was created to further the Internet and not stifle it. Nowhere do I see that it is part of ARIN's mission to somehow prevent profits via policies. Appears to me to be all about the haves keeping the have nots from obtaining resources. :-( > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Thursday, September 24, 2015 4:37 PM > To: elvis at velea.eu > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > Of course your position wouldn?t have anything to do with the profits you stand to make from an unrestricted transfer market. > > Owen > >> On Sep 24, 2015, at 13:12 , Elvis Daniel Velea wrote: >> >> Hi Owen, >> >> On 24/09/15 22:09, Owen DeLong wrote: >>> Short answer: NO >>> >>> Longer answer: >>> >>> Finance alone does not reflect all community values. Eliminating >>> needs-based evaluation for transfers will foster an environment open >>> to speculation and other artifice used to maximize the monetization of address resources without providing the benefit to the community of maximizing utilization. >> The environment open to speculation already exists, a needs-based criteria will not stop the ones that want to speculate. Keeping needs-based criteria in policy will only drive (keep some of the) transfers underground (ie: futures contracts, all kind of financial artifices). I actually believe the needs-based criteria removal will benefit the community by eliminating a barrier in the correct registration of the transfers (resources) in the registry (and whois). >> >> The allocation era has passed, ARIN should just be a shepherd and record the transfers (and do the allocation exercise twice per year, when the IANA allocates the few crumbs remaining). From my experience and observations, if someone needs the IP addresses and has the money to pay for them I am sure that they will not be stopped by ARIN's needs-base criteria... >>> In fact, I believe that eliminating needs-basis will likely cause >>> actual utilization to be reduced in the long run in favor of financial manipulation. >> I dare to disagree. From where I am standing, the removal of needs-basis criteria from the RIPE Region has increased utilization of the resources transferred through the IPv4 marketplace. >> Additionally, the removal of the needs-basis criteria has increased the number of transfers, showing that the marketplace works and is useful to hundreds (or even thousands) of companies from the region. >> >> I am not saying that the ARIN community should copy what the RIPE community has done. I am just saying that if something is working and it's usability is proven, it is rather strange to see some saying the opposite as an argument against the removal of the needs-based criteria. >>> >>> Owen >> cheers, >> elvis >>> >>>> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >>>> >>>> Now that we've reached the magic ZERO in the free pool, what does >>>> the community think about this new draft policy? >>>> >>>> Should ARIN begin the process of streamlining the IPv4 policy so >>>> that it is geared more toward the transfer market, and remove "need" >>>> as a criteria in certain sections of the NRPM to increase the database accuracy? >>>> >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>>> On Behalf Of ARIN >>>> Sent: Wednesday, September 23, 2015 12:54 PM >>>> To: arin-ppml at arin.net >>>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >>>> needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of >>>> IPv4 netblocks >>>> >>>> Draft Policy ARIN-2015-9 >>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >>>> transfers of IPv4 netblocks >>>> >>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>>> >>>> Draft Policy ARIN-2015-9 is below and can be found at: >>>> https://www.arin.net/policy/proposals/2015_9.html >>>> >>>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >>>> >>>> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >>>> >>>> * Enabling Fair and Impartial Number Resource Administration >>>> * Technically Sound >>>> * Supported by the Community >>>> >>>> The ARIN Policy Development Process (PDP) can be found at: >>>> https://www.arin.net/policy/pdp.html >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> Regards, >>>> >>>> Communications and Member Services >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> ## * ## >>>> >>>> Draft Policy ARIN-2015-9 >>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >>>> transfers of IPv4 netblocks >>>> >>>> Date: 23 September 2015 >>>> >>>> Problem statement: >>>> >>>> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >>>> Additionally, the 8.1 introduction section includes a perceived "threat" >>>> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >>>> >>>> Policy statement: >>>> >>>> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >>>> >>>> Section 8.1 Principles: >>>> >>>> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >>>> >>>> Section 8.2 Mergers and Acquisitions: >>>> >>>> - Change the 4th bullet from: >>>> >>>> "The resources to be transferred will be subject to ARIN policies." >>>> >>>> to: >>>> >>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>> >>>> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >>>> >>>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>>> >>>> - Change the first bullet under "Conditions on recipient of the transfer" from: >>>> >>>> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >>>> >>>> to: >>>> >>>> "The recipient must sign an RSA." >>>> >>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>> from: >>>> >>>> "The resources to be transferred will be subject to ARIN policies." >>>> >>>> to: >>>> >>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>> >>>> Section 8.4 Inter-RIR Transfers to Specified Recipients: >>>> >>>> - Change the introductory language from: >>>> >>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >>>> >>>> to: >>>> >>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >>>> >>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>> from: >>>> >>>> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >>>> >>>> to: >>>> >>>> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >>>> >>>> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >>>> >>>> Comments: >>>> >>>> a. Timetable for implementation: Immediate >>>> >>>> b. Anything else >>>> >>>> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, >>>> and >>>> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >>>> >>>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Sep 25 02:24:26 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Sep 2015 23:24:26 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <560464D5.6000208@matthew.at> References: <56031167.1010007@arin.net> <560464D5.6000208@matthew.at> Message-ID: <9F4C0377-26B2-4C75-9029-4D856BF5F9AF@delong.com> While it may have that desirable effect, it certainly also comes with several undesirable effects as well. Owen > On Sep 24, 2015, at 14:02 , Matthew Kaufman wrote: > > If you're right, doesn't that simply drive v6 adoption, which is the desired goal? > > > > Matthew Kaufman > > On 9/24/2015 12:09 PM, Owen DeLong wrote: >> Short answer: NO >> >> Longer answer: >> >> Finance alone does not reflect all community values. Eliminating needs-based evaluation for transfers >> will foster an environment open to speculation and other artifice used to maximize the monetization of >> address resources without providing the benefit to the community of maximizing utilization. >> >> In fact, I believe that eliminating needs-basis will likely cause actual utilization to be reduced in the >> long run in favor of financial manipulation. >> >> Owen >> >>> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >>> >>> Now that we've reached the magic ZERO in the free pool, what does the community >>> think about this new draft policy? >>> >>> Should ARIN begin the process of streamlining the IPv4 policy so that it is >>> geared more toward the transfer market, and remove "need" as a criteria in >>> certain sections of the NRPM to increase the database accuracy? >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>> Sent: Wednesday, September 23, 2015 12:54 PM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>> >>> Draft Policy ARIN-2015-9 >>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>> >>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>> >>> Draft Policy ARIN-2015-9 is below and can be found at: >>> https://www.arin.net/policy/proposals/2015_9.html >>> >>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >>> >>> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The ARIN Policy Development Process (PDP) can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Communications and Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> Draft Policy ARIN-2015-9 >>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>> >>> Date: 23 September 2015 >>> >>> Problem statement: >>> >>> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >>> Additionally, the 8.1 introduction section includes a perceived "threat" >>> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >>> >>> Policy statement: >>> >>> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >>> >>> Section 8.1 Principles: >>> >>> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >>> >>> Section 8.2 Mergers and Acquisitions: >>> >>> - Change the 4th bullet from: >>> >>> "The resources to be transferred will be subject to ARIN policies." >>> >>> to: >>> >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>> >>> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >>> >>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>> >>> - Change the first bullet under "Conditions on recipient of the transfer" from: >>> >>> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >>> >>> to: >>> >>> "The recipient must sign an RSA." >>> >>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>> from: >>> >>> "The resources to be transferred will be subject to ARIN policies." >>> >>> to: >>> >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>> >>> Section 8.4 Inter-RIR Transfers to Specified Recipients: >>> >>> - Change the introductory language from: >>> >>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >>> >>> to: >>> >>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >>> >>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>> from: >>> >>> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >>> >>> to: >>> >>> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >>> >>> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >>> >>> Comments: >>> >>> a. Timetable for implementation: Immediate >>> >>> b. Anything else >>> >>> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, and >>> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >>> >>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Sep 25 02:35:46 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Sep 2015 23:35:46 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> <29286955-3FFD-417B-98D5-B44A5183DB7D@delong.com> Message-ID: <80064C52-BDD5-4F64-96AD-B0162F974C12@delong.com> > On Sep 24, 2015, at 15:41 , John Springer wrote: > > Hi Owen, > > On Thu, 24 Sep 2015, Owen DeLong wrote: > >> >>> On Sep 24, 2015, at 12:37 , John Springer wrote: >>> >>> And if you have an opinion of no, are you able to say because it is technically unsound or unfair and partial? >> >> This isn?t really necessary, John. A proposal must be fair, technically sound, and have support of the community in order to be adopted. >> >> Just because it is technically sound and/or fair does not mean that the community must support it. >> >> People are free to reject a policy for any reason, though I admit a bias in favor of at least some rationale for rejection. >> >> Owen >> > > Oh, I think it is necessary for the community to comment on all three criteria, Owen, and I thank you for inviting them to express support or opposition. > > BTW, do you support or oppose the Draft Policy? > > John Springer I think comments on all three criteria are welcome. I don?t think anyone in particular is required to comment on any of the areas they don?t choose to. Personally, I think that this policy is unnecessary and contrary to its stated intent as written, but I need to review it more thoroughly to see if I misread something. Owen From owen at delong.com Fri Sep 25 03:01:37 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Sep 2015 00:01:37 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <84A3D992-8A5E-47A0-8831-F205E0F7B05F@delong.com> Richard did a pretty good job of expressing my thoughts as well. Owen > On Sep 24, 2015, at 20:46 , Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. > > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. > > Richard > > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net> > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From elvis at velea.eu Fri Sep 25 07:23:45 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 25 Sep 2015 14:23:45 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <0742D43D-F93C-40EF-AAB0-7B061DE1E9C1@delong.com> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> <0742D43D-F93C-40EF-AAB0-7B061DE1E9C1@delong.com> Message-ID: <56052EC1.4080201@velea.eu> Hi Owen, On 25/09/15 09:23, Owen DeLong wrote: > It?s not ARIN?s mission to prevent profits nor did I say it was. > > My point is that Elvis support for removing policy is strongly influenced by the potential windfall he stands to reap while not actually providing > any internet services in the process if the policy is changed as he wishes. Please stop implying what influences my beliefs. I doubt you can read my mind. I already said it several times that regardless of the outcome, there are plenty of organizations that have already received 'pre-approvals' and helping at least those will fill up my plate.. What do you mean we do not provide an internet service? We offer various services, not just the brokerage part. > As yo pointed out, many folks make a profit on various INETERNET SERVICES. Elvis, OTOH is not in the internet services business. He?s strictly > an address broker. What do you mean by 'not in the internet services business' ? I think you are starting to be rude and would like to ask you to back off a bit. We offer various services to our customers: IP management, LIR management, audits, Sponsoring LIR services (RIPE Region), IPv6 migration support, etc... > It would be sort of like Realtors arguing against transfer taxes on real estate. An argument based solely in greed rather than any actual concern for the common good. Again, you are just guessing why I am commenting on this policy proposal. As an ex-RIR employee, I've told you (and others) several times that I still want to do the right thing for the community. I have already made several policy proposals in the RIPE Region (one recently accepted by the community) and I am active in APNIC and now ARIN... Owen, last time we discussed you said that you understand the need of brokers and while a few years back you did not agree with us existing, now you are no longer against... I see personal attacks in the two e-mails you sent and I don't understand where these come from. Owen, please stop guessing what my business does and why I participate in the discussions. I doubt this is what an ARIN AC member should do.. regards, Elvis PS: I could have registered to the mailing list with my work e-mail address if all I wanted to do is to profit from my position on this (and other) policy proposals discussions. These messages are sent on my behalf and may or may not be the point of view of the company I work for > > Owen > >> On Sep 24, 2015, at 13:53 , Steven Ryerse wrote: >> >> Many folks make a profit on various Internet services in this Region. ARIN was created to further the Internet and not stifle it. Nowhere do I see that it is part of ARIN's mission to somehow prevent profits via policies. Appears to me to be all about the haves keeping the have nots from obtaining resources. :-( >> >> Steven Ryerse >> President >> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >> 770.656.1460 - Cell >> 770.399.9099- Office >> >> ? Eclipse Networks, Inc. >> Conquering Complex Networks? >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong >> Sent: Thursday, September 24, 2015 4:37 PM >> To: elvis at velea.eu >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> Of course your position wouldn?t have anything to do with the profits you stand to make from an unrestricted transfer market. >> >> Owen >> >>> On Sep 24, 2015, at 13:12 , Elvis Daniel Velea wrote: >>> >>> Hi Owen, >>> >>> On 24/09/15 22:09, Owen DeLong wrote: >>>> Short answer: NO >>>> >>>> Longer answer: >>>> >>>> Finance alone does not reflect all community values. Eliminating >>>> needs-based evaluation for transfers will foster an environment open >>>> to speculation and other artifice used to maximize the monetization of address resources without providing the benefit to the community of maximizing utilization. >>> The environment open to speculation already exists, a needs-based criteria will not stop the ones that want to speculate. Keeping needs-based criteria in policy will only drive (keep some of the) transfers underground (ie: futures contracts, all kind of financial artifices). I actually believe the needs-based criteria removal will benefit the community by eliminating a barrier in the correct registration of the transfers (resources) in the registry (and whois). >>> >>> The allocation era has passed, ARIN should just be a shepherd and record the transfers (and do the allocation exercise twice per year, when the IANA allocates the few crumbs remaining). From my experience and observations, if someone needs the IP addresses and has the money to pay for them I am sure that they will not be stopped by ARIN's needs-base criteria... >>>> In fact, I believe that eliminating needs-basis will likely cause >>>> actual utilization to be reduced in the long run in favor of financial manipulation. >>> I dare to disagree. From where I am standing, the removal of needs-basis criteria from the RIPE Region has increased utilization of the resources transferred through the IPv4 marketplace. >>> Additionally, the removal of the needs-basis criteria has increased the number of transfers, showing that the marketplace works and is useful to hundreds (or even thousands) of companies from the region. >>> >>> I am not saying that the ARIN community should copy what the RIPE community has done. I am just saying that if something is working and it's usability is proven, it is rather strange to see some saying the opposite as an argument against the removal of the needs-based criteria. >>>> Owen >>> cheers, >>> elvis >>>>> On Sep 24, 2015, at 11:55 , Leif Sawyer wrote: >>>>> >>>>> Now that we've reached the magic ZERO in the free pool, what does >>>>> the community think about this new draft policy? >>>>> >>>>> Should ARIN begin the process of streamlining the IPv4 policy so >>>>> that it is geared more toward the transfer market, and remove "need" >>>>> as a criteria in certain sections of the NRPM to increase the database accuracy? >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>>>> On Behalf Of ARIN >>>>> Sent: Wednesday, September 23, 2015 12:54 PM >>>>> To: arin-ppml at arin.net >>>>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >>>>> needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of >>>>> IPv4 netblocks >>>>> >>>>> Draft Policy ARIN-2015-9 >>>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >>>>> transfers of IPv4 netblocks >>>>> >>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>> "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>>>> >>>>> Draft Policy ARIN-2015-9 is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2015_9.html >>>>> >>>>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-9 on the Public Policy Mailing List. >>>>> >>>>> The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: >>>>> >>>>> * Enabling Fair and Impartial Number Resource Administration >>>>> * Technically Sound >>>>> * Supported by the Community >>>>> >>>>> The ARIN Policy Development Process (PDP) can be found at: >>>>> https://www.arin.net/policy/pdp.html >>>>> >>>>> Draft Policies and Proposals under discussion can be found at: >>>>> https://www.arin.net/policy/proposals/index.html >>>>> >>>>> Regards, >>>>> >>>>> Communications and Member Services >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> ## * ## >>>>> >>>>> Draft Policy ARIN-2015-9 >>>>> Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >>>>> transfers of IPv4 netblocks >>>>> >>>>> Date: 23 September 2015 >>>>> >>>>> Problem statement: >>>>> >>>>> The current policies in NRPM sections 8.2, 8.3, and 8.4 regarding transfer of IPv4 netblocks from one organization to another are currently a hindrance in ensuring database accuracy. In practice, ARIN staff are utilizing those polices to refuse to complete database updates which would reflect an accurate transfer of control / utilization of netblocks in cases where ARIN doesn't agree that the recipient organization has need, or more often where the recipient organization bypasses the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. >>>>> Additionally, the 8.1 introduction section includes a perceived "threat" >>>>> of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates when transferring resources. The result is that the data visible in ARIN registry continues to become more inaccurate over time. >>>>> >>>>> Policy statement: >>>>> >>>>> This proposal is for the following language changes in the respective NRPM sections in order to eliminate all needs-based evaluation for the respective transfer type, and allow transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. >>>>> >>>>> Section 8.1 Principles: >>>>> >>>>> - Strike the 3rd paragraph which begins with "Number resources are issued, based on justified need, to organizations. . ." since it mostly reiterates other sections of ARIN policy. All transfers are subjected to those policies, as called out in 8.2, 8.3, 8.4. Additionally, removing this paragraph removes the perceived "threat" of reclaim which serves as a hindrance to long-term resource holders approaching ARIN with database updates, since in practice ARIN has not been forcibly reclaiming IP resources assigned to "failed businesses." >>>>> >>>>> Section 8.2 Mergers and Acquisitions: >>>>> >>>>> - Change the 4th bullet from: >>>>> >>>>> "The resources to be transferred will be subject to ARIN policies." >>>>> >>>>> to: >>>>> >>>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>>> >>>>> - Remove entirely the last paragraph which reads "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy." >>>>> >>>>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>>>> >>>>> - Change the first bullet under "Conditions on recipient of the transfer" from: >>>>> >>>>> "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." >>>>> >>>>> to: >>>>> >>>>> "The recipient must sign an RSA." >>>>> >>>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>>> from: >>>>> >>>>> "The resources to be transferred will be subject to ARIN policies." >>>>> >>>>> to: >>>>> >>>>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate." >>>>> >>>>> Section 8.4 Inter-RIR Transfers to Specified Recipients: >>>>> >>>>> - Change the introductory language from: >>>>> >>>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." >>>>> >>>>> to: >>>>> >>>>> "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, policies." >>>>> >>>>> - Change the 2nd bullet under "Conditions on recipient of the transfer" >>>>> from: >>>>> >>>>> "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." >>>>> >>>>> to: >>>>> >>>>> "Recipients within the ARIN region will be subject to current ARIN policies, excluding any policies related to needs-based justification or inspection of current or future utilization rate, and sign an RSA for the resources being received." >>>>> >>>>> - Remove entirely the 3rd bullet under "Conditions on recipient of the transfer" which reads "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." >>>>> >>>>> Comments: >>>>> >>>>> a. Timetable for implementation: Immediate >>>>> >>>>> b. Anything else >>>>> >>>>> As the "free pool" for 4 of the 5 world's RIRs (APNIC, RIPE, LACNIC, >>>>> and >>>>> ARIN) has now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfil that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to "documentation." In other words, the focus must move away from practicing conservation and fair distribution (e.g. following guidelines set forth in RFC2050) to ensuring an accurate registry database of which organization is utilizing a given netblock as a result of transfers which occur between organizations. >>>>> >>>>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. >>>>> >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to the >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the ARIN >>>> Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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 elvis at velea.eu Fri Sep 25 07:42:22 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 25 Sep 2015 14:42:22 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <5605331E.30306@velea.eu> Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: > b) > There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? > > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. > Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. > > Richard regards, Elvis > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net> > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Sep 25 13:24:17 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Sep 2015 10:24:17 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <5605331E.30306@velea.eu> References: <5605331E.30306@velea.eu> Message-ID: > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea wrote: > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: >> b) >> There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. > the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. >> >> It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. > So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? > Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). > Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. > I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. >> Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. > The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen >> >> Richard > regards, > Elvis >> >> ________________________________________ >> From: arin-ppml-bounces at arin.net on behalf of Dani Roisman >> Sent: Thursday, September 24, 2015 6:20 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> | Date: Wed, 23 Sep 2015 16:53:59 -0400 >> | From: ARIN >> | To: arin-ppml at arin.net >> | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based >> | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> | Message-ID: <56031167.1010007 at arin.net> >> | Content-Type: text/plain; charset=utf-8; format=flowed >> | >> | Draft Policy ARIN-2015-9 >> | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >> | transfers of IPv4 netblocks >> | >> | On 17 September 2015 the ARIN Advisory Council (AC) accepted >> | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, >> | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >> | >> | Draft Policy ARIN-2015-9 is below and can be found at: >> | https://www.arin.net/policy/proposals/2015_9.html >> >> Greetings, >> >> There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: >> a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? >> b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? >> >> -- >> Dani Roisman >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Fri Sep 25 13:48:10 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Sep 2015 17:48:10 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From owen at delong.com Fri Sep 25 14:48:00 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Sep 2015 11:48:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: > On Sep 25, 2015, at 10:48 , Steven Ryerse wrote: > > Owens comment from below: > ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? > > Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! This is patently false. Many small organizations have gotten resources from ARIN. I have no problem with the open market so long as it conforms to the same needs-basis evaluations that were used for free pool assignments/allocations. Sure, organizations with larger needs have the option of getting less resources than they need, but I don?t see how that differs from what I said. Organizations with small needs can get what they need, assuming there is supply. I did not distinguish between supply from the market and supply from the free pool as I believe the rules should apply the same regardless of the source of resources. You say my statement is false and then go on to confirm that it is actually true. > It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! What inequity? You haven?t yet shown one. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Sep 25 14:56:51 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Sep 2015 11:56:51 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <56052EC1.4080201@velea.eu> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> <0742D43D-F93C-40EF-AAB0-7B061DE1E9C1@delong.com> <56052EC1.4080201@velea.eu> Message-ID: > On Sep 25, 2015, at 04:23 , Elvis Daniel Velea wrote: > > Hi Owen, > > On 25/09/15 09:23, Owen DeLong wrote: >> It?s not ARIN?s mission to prevent profits nor did I say it was. >> >> My point is that Elvis support for removing policy is strongly influenced by the potential windfall he stands to reap while not actually providing >> any internet services in the process if the policy is changed as he wishes. > Please stop implying what influences my beliefs. I doubt you can read my mind. > > I already said it several times that regardless of the outcome, there are plenty of organizations that have already received 'pre-approvals' and helping at least those will fill up my plate.. What do you mean we do not provide an internet service? We offer various services, not just the brokerage part. >> As yo pointed out, many folks make a profit on various INETERNET SERVICES. Elvis, OTOH is not in the internet services business. He?s strictly >> an address broker. > What do you mean by 'not in the internet services business' ? I think you are starting to be rude and would like to ask you to back off a bit. > We offer various services to our customers: IP management, LIR management, audits, Sponsoring LIR services (RIPE Region), IPv6 migration support, etc? Do you offer any services involving moving bits between your clients and other organizations? Or are you strictly in the address marketing/management business? From everything you have said to me, I?ve been led to believe the latter. If you actually sell access or transit services, hosting, or anything like that, then I stand corrected. >> It would be sort of like Realtors arguing against transfer taxes on real estate. An argument based solely in greed rather than any actual concern for the common good. > Again, you are just guessing why I am commenting on this policy proposal. As an ex-RIR employee, I've told you (and others) several times that I still want to do the right thing for the community. I have already made several policy proposals in the RIPE Region (one recently accepted by the community) and I am active in APNIC and now ARIN? Fair enough, but I?d call it an educated guess based on conversations we?ve had. > > Owen, last time we discussed you said that you understand the need of brokers and while a few years back you did not agree with us existing, now you are no longer against... I see personal attacks in the two e-mails you sent and I don't understand where these come from. Not exactly. I said I understand the needs of brokers, not that I saw a need for brokers. Understanding the needs of brokers does not imply a desire to accommodate them. I did say that I am not opposed to brokers existing and I am not. However, I?m not in favor of supporting them to the detriment of the community, either. In fact, I have worked with brokers to get IP addresses for organizations. I see no incompatibility between needs basis and brokers working above board. Your repeated expressions of willingness to conduct transfers outside the system if you can?t do whatever you want within the system are where I take exception. These have been your own words even in this very thread. I?m sorry you see those as personal attacks. What I am attacking is the idea of contorting policy to suit the profit motives of an ancillary industry to the detriment of those actually building and operating infrastructure. It was never my intent to attack you personally. > Owen, please stop guessing what my business does and why I participate in the discussions. I doubt this is what an ARIN AC member should do.. I didn?t think I was guessing what your business did. Everything I said was based on what you told me your business did. I?m sorry if I misunderstood or got it wrong. I will make clear that my posts here are as a member of the community and not in any official capacity as a member of the AC. Owen From mwinters at edwardrose.com Fri Sep 25 15:03:02 2015 From: mwinters at edwardrose.com (Mike Winters) Date: Fri, 25 Sep 2015 19:03:02 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: That?s an interesting take on the ?inequity?? However, there is a fundamental flaw with your ?inequity? situation. If there is not enough addresses for a small organization to get them, then nobody would get them. They will eventually rise to the top just like everyone else, ergo no inequity. Assuming for a moment your argument is correct and not seriously flawed, then arguing that letting people who don?t need addresses get addresses is silly since it would only exacerbate the problem. It seems the best way to ?fix this inequity? that you describe would be to either: a) not let larger organizations accept smaller allocations; or b) make everyone take smaller allocations; or c) let ARIN allocate smaller blocks (really bad idea); or d) some crazy combination of the above Neither of the above really helps anyone and probably creates a host of other issues. To be clear, I am not advocating any of the above. Mike From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 1:48 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From SRyerse at eclipse-networks.com Fri Sep 25 15:05:03 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Sep 2015 19:05:03 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: <91dac34814f04b7e8b05bb2ea11e5c09@eni-mail1.eclipse-networks.com> From Owen?s Comments below: ?What inequity? You haven?t yet shown one.? With run-out here, it is time to turn that around. You need to prove that Needs Testing is still needed in the post Run-Out period. Everything has changed and it is a different Internet world we are now living in. Since removal of Needs Testing has NOT been tried in this RIR, you are just guessing what the effect on available resources will be. Elvis made a pretty good argument in this thread that Needs Testing is no longer needed. He describes what is happening in real life with resources in other RIR?s which counter your argument ? and it is not a guess. It?s pretty obvious that if needs testing goes away, Legacy blocks will become much more available to anyone who needs them, and as Elvis indicated the Database will become much more accurate. When any small Organization requesting a very small amount of resources is completely denied resources because of arbitrary ?policy?, ARIN has done the opposite of the Mission it was founded to perform! As I said the time has come to fix this inequity and embrace the new Internet world we are now in. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, September 25, 2015 2:48 PM To: Steven Ryerse Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 10:48 , Steven Ryerse > wrote: Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! This is patently false. Many small organizations have gotten resources from ARIN. I have no problem with the open market so long as it conforms to the same needs-basis evaluations that were used for free pool assignments/allocations. Sure, organizations with larger needs have the option of getting less resources than they need, but I don?t see how that differs from what I said. Organizations with small needs can get what they need, assuming there is supply. I did not distinguish between supply from the market and supply from the free pool as I believe the rules should apply the same regardless of the source of resources. You say my statement is false and then go on to confirm that it is actually true. It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! What inequity? You haven?t yet shown one. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From stephen at sprunk.org Fri Sep 25 15:25:37 2015 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 25 Sep 2015 14:25:37 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: <56059FB1.8000808@sprunk.org> On 25-Sep-15 12:48, Steven Ryerse wrote: > Owens comment from below: > > ?2. To the extent that there is supply, anyone who needs addresses > can get them already. Needs-based evaluation does not prevent those > with need from getting addresses? It prevents those without need from > getting them.? > > Owen?s comment is absolutely false!!!!! It allows large organizing > who request resources to get what they need or something smaller. It > allows medium size organizations who request resources to get what > they need or something smaller. It allows small organizations who > request resources to get what they need or nothing, and there is no > other source to get resources if ARIN rejects a request, but the open > market which Owen and others seem to wish did not exist! > > It is time to fix this inequity and removing needs tests would be a > big help to small organizations who really need resources! If they actually need the resources, then a needs-based policy does not present an obstacle. Where's the problem? However, not having such a policy will mean that folks who _don't_ need resources can also get them, which makes the (IPv4) scarcity problem even worse than it already is. That benefits speculators at the expense of those who actually need resources. You appear to be arguing against your stated interests. 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2414 bytes Desc: S/MIME Cryptographic Signature URL: From SRyerse at eclipse-networks.com Fri Sep 25 15:32:02 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Sep 2015 19:32:02 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: I would probably agree with your comment that neither of the above really helps anyone and probably creates a host of other issues. I would probably not advocate them either but they would be more fair that the policies in place now. Of course the easy fix is to allow Organizations of any size to easily get the Minimum size block which I believe is now a /24 and that would go a long way towards fixing the problem. I put forth just that policy change proposal a while back with a limit of one block per year for small organizations and that Policy Proposal was summarily dumped by folks with Owen?s views. My preference is to allow organizations to more easily get resources in this post Run-Out world, rather than to somehow try to miserly block allocations in the hope of saving them for some unknown future use. I appreciate your attempt to be constructive. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Mike Winters [mailto:mwinters at edwardrose.com] Sent: Friday, September 25, 2015 3:03 PM To: Steven Ryerse Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks That?s an interesting take on the ?inequity?? However, there is a fundamental flaw with your ?inequity? situation. If there is not enough addresses for a small organization to get them, then nobody would get them. They will eventually rise to the top just like everyone else, ergo no inequity. Assuming for a moment your argument is correct and not seriously flawed, then arguing that letting people who don?t need addresses get addresses is silly since it would only exacerbate the problem. It seems the best way to ?fix this inequity? that you describe would be to either: a) not let larger organizations accept smaller allocations; or b) make everyone take smaller allocations; or c) let ARIN allocate smaller blocks (really bad idea); or d) some crazy combination of the above Neither of the above really helps anyone and probably creates a host of other issues. To be clear, I am not advocating any of the above. Mike From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 1:48 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From stephen at sprunk.org Fri Sep 25 15:32:59 2015 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 25 Sep 2015 14:32:59 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <91dac34814f04b7e8b05bb2ea11e5c09@eni-mail1.eclipse-networks.com> References: <5605331E.30306@velea.eu> <91dac34814f04b7e8b05bb2ea11e5c09@eni-mail1.eclipse-networks.com> Message-ID: <5605A16B.5010109@sprunk.org> On 25-Sep-15 14:05, Steven Ryerse wrote: > It?s pretty obvious that if needs testing goes away, Legacy blocks will >become much more available to anyone who needs them, ... If so, only because it allows speculators to drive up the market price, which is not in the interests of those who actually need resources. > When any small Organization requesting a very small amount of > resources is completely denied resources because of arbitrary > ?policy?, ARIN policy is not arbitrary, and it's set by the community; if you see a problem with how needs testing is done, feel free to suggest changes. If your complaint is actually that the minimum block size is not small enough, that is an entirely different problem from needs testing. 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2414 bytes Desc: S/MIME Cryptographic Signature URL: From SRyerse at eclipse-networks.com Fri Sep 25 15:33:24 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Sep 2015 19:33:24 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <56059FB1.8000808@sprunk.org> References: <5605331E.30306@velea.eu> <56059FB1.8000808@sprunk.org> Message-ID: It appears to me that you are still trying to somehow save IPv4 from exhaustion. That horse is out of the barn and gone. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stephen Sprunk Sent: Friday, September 25, 2015 3:26 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On 25-Sep-15 12:48, Steven Ryerse wrote: > Owens comment from below: > > ?2. To the extent that there is supply, anyone who needs addresses > can get them already. Needs-based evaluation does not prevent those > with need from getting addresses? It prevents those without need from > getting them.? > > Owen?s comment is absolutely false!!!!! It allows large organizing > who request resources to get what they need or something smaller. It > allows medium size organizations who request resources to get what > they need or something smaller. It allows small organizations who > request resources to get what they need or nothing, and there is no > other source to get resources if ARIN rejects a request, but the open > market which Owen and others seem to wish did not exist! > > It is time to fix this inequity and removing needs tests would be a > big help to small organizations who really need resources! If they actually need the resources, then a needs-based policy does not present an obstacle. Where's the problem? However, not having such a policy will mean that folks who _don't_ need resources can also get them, which makes the (IPv4) scarcity problem even worse than it already is. That benefits speculators at the expense of those who actually need resources. You appear to be arguing against your stated interests. 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From owen at delong.com Fri Sep 25 15:45:33 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Sep 2015 12:45:33 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: <303C4CA8-78B4-4E1D-9ECF-3EF9EB7CF255@delong.com> Your proposal was to allow anyone to get a /24 per year whether they needed anything or not. I am not opposed to a policy which would allow organizations with lesser need to obtain a minimum size block (/24 or /48) if the potential for abuse can be adequately addressed. By abuse, I mean, for example, the creation of entities with minimalist infrastructure strictly for the sake of qualifying for addresses. I?m all for the local bakery to be able to get a /24 to support their 3 cash registers, a router, and a few menu board displays. However, I?m not for VPNs-R-US being able to create 1024 entities each of which owns an SRX-100 and qualifies for a /24 on that basis. I don?t think resource policy should substantially change in a post-runout world and nothing said so far gives me any reason to believe there is benefit to the community from doing so. This isn't about miserly blocking of allocations for future theoretical use. This is about trying to make sure that organizations with need have the best chance of getting resources they need that we can provide. Allowing organizations without need to hoard addresses is contrary to that goal. Interestingly, we seem to have the same goal but radically different opinions on how best to achieve it. Owen > On Sep 25, 2015, at 12:32 , Steven Ryerse wrote: > > I would probably agree with your comment that neither of the above really helps anyone and probably creates a host of other issues. I would probably not advocate them either but they would be more fair that the policies in place now. > > Of course the easy fix is to allow Organizations of any size to easily get the Minimum size block which I believe is now a /24 and that would go a long way towards fixing the problem. I put forth just that policy change proposal a while back with a limit of one block per year for small organizations and that Policy Proposal was summarily dumped by folks with Owen?s views. > > My preference is to allow organizations to more easily get resources in this post Run-Out world, rather than to somehow try to miserly block allocations in the hope of saving them for some unknown future use. > > I appreciate your attempt to be constructive. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: Mike Winters [mailto:mwinters at edwardrose.com] > Sent: Friday, September 25, 2015 3:03 PM > To: Steven Ryerse > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > That?s an interesting take on the ?inequity?? > > However, there is a fundamental flaw with your ?inequity? situation. If there is not enough addresses for a small organization to get them, then nobody would get them. > They will eventually rise to the top just like everyone else, ergo no inequity. > > Assuming for a moment your argument is correct and not seriously flawed, then arguing that letting people who don?t need addresses get addresses is silly since it would only exacerbate the problem. > It seems the best way to ?fix this inequity? that you describe would be to either: > a) not let larger organizations accept smaller allocations; or > b) make everyone take smaller allocations; or > c) let ARIN allocate smaller blocks (really bad idea); or > d) some crazy combination of the above > > Neither of the above really helps anyone and probably creates a host of other issues. > To be clear, I am not advocating any of the above. > > Mike > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Steven Ryerse > Sent: Friday, September 25, 2015 1:48 PM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > Owens comment from below: > ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? > > Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! > > It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong > Sent: Friday, September 25, 2015 1:24 PM > To: elvis at velea.eu > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. > the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? > > Sure, except it isn?t actually an outcome of the proposal on many levels: > > 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. > 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. > 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. > > > > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. > So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? > Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). > > > Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. > > OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. > > > I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. > > I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. > > > Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. > The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. > > Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? > > Owen > > > > Richard > regards, > Elvis > > > ________________________________________ > From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net > > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Fri Sep 25 15:54:22 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Sep 2015 19:54:22 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <5605A16B.5010109@sprunk.org> References: <5605331E.30306@velea.eu> <91dac34814f04b7e8b05bb2ea11e5c09@eni-mail1.eclipse-networks.com> <5605A16B.5010109@sprunk.org> Message-ID: <4e8caa31f0fd44efaead6285e9e5fc38@eni-mail1.eclipse-networks.com> Obviously you are entitled to your opinion and I respect it, but I don?t share it. Market price is driven by supply and demand and there is actually quite a supply of IPv4 resources out there in the huge amount of Legacy blocks that were issued before ARIN existed. If this community would fully embrace the transfers of these blocks in a way that encouraged, instead of discouraged, bringing those into the ARIN sphere - I think there would be so many blocks become available, the price would go way way down because of oversupply. I know John will tell us that ARIN already has a mechanism for that built into current policy and that some Legacy blocks have become available thru that policy, but the fact that a large number of transactions continue to completely go around ARIN is indication that those Legacy holders do not want to abide by current ARIN policy. So this community can refuse to make the changes to policy that would make these resources available above board on the open market, or it can continue to refuse to change and watch prices continue to rise until only big Orgs can afford them. At some point IPv6 might be the solution but until then IPv4 resources continues to be required. I think it is about time for this community to truly embrace the Legacy holders and I hope others come to that conclusion as well. Maybe we need IPv4 Amnesty. My two cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stephen Sprunk Sent: Friday, September 25, 2015 3:33 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On 25-Sep-15 14:05, Steven Ryerse wrote: > It?s pretty obvious that if needs testing goes away, Legacy blocks will > become much more available to anyone who needs them, ... If so, only because it allows speculators to drive up the market price, which is not in the interests of those who actually need resources. > When any small Organization requesting a very small amount of > resources is completely denied resources because of arbitrary > ?policy?, ARIN policy is not arbitrary, and it's set by the community; if you see a problem with how needs testing is done, feel free to suggest changes. If your complaint is actually that the minimum block size is not small enough, that is an entirely different problem from needs testing. 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From bill at tknow.com Fri Sep 25 16:05:31 2015 From: bill at tknow.com (Bill Buhler) Date: Fri, 25 Sep 2015 20:05:31 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From SRyerse at eclipse-networks.com Fri Sep 25 16:07:22 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Sep 2015 20:07:22 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <303C4CA8-78B4-4E1D-9ECF-3EF9EB7CF255@delong.com> References: <5605331E.30306@velea.eu> <303C4CA8-78B4-4E1D-9ECF-3EF9EB7CF255@delong.com> Message-ID: <22d7ed30e0c44bd7ae85c424aea092e3@eni-mail1.eclipse-networks.com> So explain to me how anyone can corner the market on IPv4 blocks when they can only get one /24 per year without going thru your needs testing. They have to pay ARIN for them every year so in 3 years they can get up to 3 /24?s as long as they are willing to pay for them every year they have them. If they stop paying they lose the resources. This is a miniscule amount of resources, and I respectfully submit it would not appreciably change the availability of resources for anyone. It hasn?t in other regions as Elvis pointed out. It would however make a big difference to small Organizations and level the playing field. We are not far apart conceptually but we are far apart in what actually happens. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, September 25, 2015 3:46 PM To: Steven Ryerse Cc: Mike Winters ; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Your proposal was to allow anyone to get a /24 per year whether they needed anything or not. I am not opposed to a policy which would allow organizations with lesser need to obtain a minimum size block (/24 or /48) if the potential for abuse can be adequately addressed. By abuse, I mean, for example, the creation of entities with minimalist infrastructure strictly for the sake of qualifying for addresses. I?m all for the local bakery to be able to get a /24 to support their 3 cash registers, a router, and a few menu board displays. However, I?m not for VPNs-R-US being able to create 1024 entities each of which owns an SRX-100 and qualifies for a /24 on that basis. I don?t think resource policy should substantially change in a post-runout world and nothing said so far gives me any reason to believe there is benefit to the community from doing so. This isn't about miserly blocking of allocations for future theoretical use. This is about trying to make sure that organizations with need have the best chance of getting resources they need that we can provide. Allowing organizations without need to hoard addresses is contrary to that goal. Interestingly, we seem to have the same goal but radically different opinions on how best to achieve it. Owen On Sep 25, 2015, at 12:32 , Steven Ryerse > wrote: I would probably agree with your comment that neither of the above really helps anyone and probably creates a host of other issues. I would probably not advocate them either but they would be more fair that the policies in place now. Of course the easy fix is to allow Organizations of any size to easily get the Minimum size block which I believe is now a /24 and that would go a long way towards fixing the problem. I put forth just that policy change proposal a while back with a limit of one block per year for small organizations and that Policy Proposal was summarily dumped by folks with Owen?s views. My preference is to allow organizations to more easily get resources in this post Run-Out world, rather than to somehow try to miserly block allocations in the hope of saving them for some unknown future use. I appreciate your attempt to be constructive. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: Mike Winters [mailto:mwinters at edwardrose.com] Sent: Friday, September 25, 2015 3:03 PM To: Steven Ryerse > Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks That?s an interesting take on the ?inequity?? However, there is a fundamental flaw with your ?inequity? situation. If there is not enough addresses for a small organization to get them, then nobody would get them. They will eventually rise to the top just like everyone else, ergo no inequity. Assuming for a moment your argument is correct and not seriously flawed, then arguing that letting people who don?t need addresses get addresses is silly since it would only exacerbate the problem. It seems the best way to ?fix this inequity? that you describe would be to either: a) not let larger organizations accept smaller allocations; or b) make everyone take smaller allocations; or c) let ARIN allocate smaller blocks (really bad idea); or d) some crazy combination of the above Neither of the above really helps anyone and probably creates a host of other issues. To be clear, I am not advocating any of the above. Mike From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 1:48 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From SRyerse at eclipse-networks.com Fri Sep 25 16:16:22 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 25 Sep 2015 20:16:22 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: <77c8ea3108a647b6b958db35255971a1@eni-mail1.eclipse-networks.com> There was a proposal similar to that in the last year and it had more folks from this community by far agreeing with it than any proposal on this subject I have ever seen since I joined this community. I would be very much in favor of your proposal! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Bill Buhler [mailto:bill at tknow.com] Sent: Friday, September 25, 2015 4:06 PM To: Steven Ryerse ; Owen DeLong Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From hannigan at gmail.com Fri Sep 25 16:26:06 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 25 Sep 2015 16:26:06 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: On Thu, Sep 24, 2015 at 11:46 PM, Richard J. Letts wrote: > b) > There is no definitive outcome from the policy change, which makes me feel > that it's not worth changing -- the problem statement argument is weak at > best. > > It is potentially enabling organizations with more money than need gain > more resources, potentially at the expense of non-profit and educational > organizations who might not be able to raise cash for additional IPv4 space > [or equipment to support a transition to IPv6]. Changing policy just to > (potentially) improve the accuracy of a database seems not worth the > (potential) risk. > > If they can't raise capital to acquire the addresses they're out of the game regardless of this proposal being policy or needs ascertainment in general. One could argue that lifting the burden on smaller and larger networks alike provide for wider benefit and ease of access, sans capital, to the addresses. You might be able to argue that hoarding would limit supply and increase cost, but I can tell you that the vast majority of business is not going to spend money speculating on address need. Kinda not how business works. It is in fact ARINs job to maintain a reliable and accurate directory. The proposal seems to line up perfectly from that perspective. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Fri Sep 25 16:35:51 2015 From: mike at iptrading.com (Mike Burns) Date: Fri, 25 Sep 2015 16:35:51 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: <03f401d0f7d1$c5059f90$4f10deb0$@iptrading.com> Hi Bill, Interesting proposal. I will note that RIPE allowed a /22 to each new LIR without a needs test, and enterprising individuals began spinning up LIRs just to get that /22 only to transfer or sell it immediately. In our case, though, the buyers will be paying market price for the addresses, not getting nearly free ones from ARIN. So I doubt we would see people spinning up ARIN organizations just to get around the needs test. If they wanted to get around the needs test, there are many options already available for that at much lower expense. Steven is right, there was a proposal last year to allow non-needs tested transfers up to a certain size, one per year. Maybe it should be dusted off. Regards, Mike From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Buhler Sent: Friday, September 25, 2015 4:06 PM To: Steven Ryerse ; Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net > | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: not available URL: From kevinb at thewire.ca Fri Sep 25 16:40:50 2015 From: kevinb at thewire.ca (Kevin Blumberg) Date: Fri, 25 Sep 2015 20:40:50 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <7E7773B523E82C478734E793E58F69E78DD2F577@SBS2011.thewireinc.local> Dani, Some observations only. 1) I'm generally not in favour of text that overrides all policy. I believe it is better to contain the policy that you are looking for. I have found that there can very easily be unintended repercussions. ie. Would the current text in the policy allow an organization to get space from a reserved free pool block and then transfer it? 2) I have been looking at this from a slightly different angle. Instead of the word "Need" maybe "Criteria" is better suited to the discussion. The term "Need" is a small piece of the policy puzzle, the "Criteria" is what defines it. Thanks, Kevin Blumberg > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Dani Roisman > Sent: Thursday, September 24, 2015 9:21 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net> > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to > ask that in addition to any overall support or lack thereof, you also review the > policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any > refinements to the changes made which you think will improve this should > these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any > adjustments to the policy changes which, if implemented, would gain your > support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Fri Sep 25 17:13:35 2015 From: farmer at umn.edu (David Farmer) Date: Fri, 25 Sep 2015 16:13:35 -0500 Subject: [arin-ppml] 11 Proposals Under Consideration Message-ID: <5605B8FF.9000602@umn.edu> There are currently 11 proposals under various stages of consideration and development in the ARIN Policy Development Process; > Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments > Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy > Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations > Draft Policy ARIN-2015-5: Out of region use > Draft Policy ARIN-2015-6: Transfers and Multi-national Networks > Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers > Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users > Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > Draft Policy ARIN-2015-10: Minimum IPv6 Assignments > Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool For details on any of theses please see; https://www.arin.net/policy/proposals/ It would be helpful if everyone takes the time to review and comment on all the proposals. I have seen lots of activity on one particular proposal in the last few days, this is good. However, anyone who has commented multiple time on this same proposals, it would be very helpful if you would also take the time to review and comment on the other proposals as well. Thank you. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From andrew.dul at quark.net Fri Sep 25 18:17:42 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 25 Sep 2015 15:17:42 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <22d7ed30e0c44bd7ae85c424aea092e3@eni-mail1.eclipse-networks.com> References: <5605331E.30306@velea.eu> <303C4CA8-78B4-4E1D-9ECF-3EF9EB7CF255@delong.com> <22d7ed30e0c44bd7ae85c424aea092e3@eni-mail1.eclipse-networks.com> Message-ID: <5605C806.4010409@quark.net> One might want to be reminded about what happened in the RIPE region when they allowed organizations to obtain /22 blocks by just opening a new LIR. There are lots of threads in the RIPE mailing-list that you can go read through if you desire. Here is a link to the outcome, a policy that restricts block flipping. https://www.ripe.net/participate/policies/proposals/2015-01 Yes, a /24 is not a /22, but if you decide that an organization can just come and get a free block, people will find ways to abuse the system. This doesn't apply in the ARIN region now, because our free pool is empty, but still we can see what happens when incentives are misaligned in resource allocation. Andrew On 9/25/2015 1:07 PM, Steven Ryerse wrote: > > So explain to me how anyone can corner the market on IPv4 blocks when > they can only get one /24 per year without going thru your needs > testing. They have to pay ARIN for them every year so in 3 years they > can get up to 3 /24?s as long as they are willing to pay for them > every year they have them. If they stop paying they lose the resources. > > > > This is a miniscule amount of resources, and I respectfully submit it > would not appreciably change the availability of resources for anyone. > It hasn?t in other regions as Elvis pointed out. It would however > make a big difference to small Organizations and level the playing field. > > > > We are not far apart conceptually but we are far apart in what > actually happens. > > > > /Steven Ryerse/ > > /President/ > > /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ > > /770.656.1460 - Cell/ > > /770.399.9099- Office/ > > > > Description: Description: Eclipse Networks Logo_small.png?Eclipse > Networks, Inc. > > ^ Conquering Complex Networks ^? ^ > > > > *From:*Owen DeLong [mailto:owen at delong.com] > *Sent:* Friday, September 25, 2015 3:46 PM > *To:* Steven Ryerse > *Cc:* Mike Winters ; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 > netblocks > > > > Your proposal was to allow anyone to get a /24 per year whether they > needed anything or not. > > > > I am not opposed to a policy which would allow organizations with > lesser need to obtain a minimum size block (/24 or /48) if the > potential for abuse can be adequately addressed. > > > > By abuse, I mean, for example, the creation of entities with > minimalist infrastructure strictly for the sake of qualifying for > addresses. > > > > I?m all for the local bakery to be able to get a /24 to support their > 3 cash registers, a router, and a few menu board displays. > > > > However, I?m not for VPNs-R-US being able to create 1024 entities each > of which owns an SRX-100 and qualifies for a /24 on that basis. > > > > I don?t think resource policy should substantially change in a > post-runout world and nothing said so far gives me any reason to > believe there is benefit to the community from doing so. > > > > This isn't about miserly blocking of allocations for future > theoretical use. This is about trying to make sure that organizations > with need have the best chance of getting resources they need that we > can provide. Allowing organizations without need to hoard addresses is > contrary to that goal. > > > > Interestingly, we seem to have the same goal but radically different > opinions on how best to achieve it. > > > > Owen > > > > On Sep 25, 2015, at 12:32 , Steven Ryerse > > wrote: > > > > I would probably agree with your comment that neither of the above > really helps anyone and probably creates a host of other issues. I > would probably not advocate them either but they would be more > fair that the policies in place now. > > > > Of course the easy fix is to allow Organizations of any size to > easily get the Minimum size block which I believe is now a /24 and > that would go a long way towards fixing the problem. I put forth > just that policy change proposal a while back with a limit of one > block per year for small organizations and that Policy Proposal > was summarily dumped by folks with Owen?s views. > > > > My preference is to allow organizations to more easily get > resources in this post Run-Out world, rather than to somehow try > to miserly block allocations in the hope of saving them for some > unknown future use. > > > > I appreciate your attempt to be constructive. > > > > /Steven Ryerse/ > > /President/ > > /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ > > /770.656.1460 - Cell/ > > /770.399.9099- Office/ > > > > ? Eclipse Networks, Inc. > > ^ Conquering Complex Networks ^? > > > > *From:* Mike Winters [mailto:mwinters at edwardrose.com] > *Sent:* Friday, September 25, 2015 3:03 PM > *To:* Steven Ryerse > > *Cc:* arin-ppml at arin.net > *Subject:* RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of > IPv4 netblocks > > > > That?s an interesting take on the ?inequity?? > > > > However, there is a fundamental flaw with your ?inequity? > situation. If there is not enough addresses for a small > organization to get them, then nobody would get them. > > They will eventually rise to the top just like everyone else, ergo > no inequity. > > > > Assuming for a moment your argument is correct and not seriously > flawed, then arguing that letting people who don?t need addresses > get addresses is silly since it would only exacerbate the problem. > > It seems the best way to ?fix this inequity? that you describe > would be to either: > > a) not let larger organizations accept smaller allocations; or > > b) make everyone take smaller allocations; or > > c) let ARIN allocate smaller blocks (really bad idea); or > > d) some crazy combination of the above > > > > Neither of the above really helps anyone and probably creates a > host of other issues. > > To be clear, I am not advocating any of the above. > > > > Mike > > > > > > *From:* arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Steven Ryerse > *Sent:* Friday, September 25, 2015 1:48 PM > *To:* Owen DeLong > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of > IPv4 netblocks > > > > Owens comment from below: > > ?2. To the extent that there is supply, anyone who needs addresses > can get them already. Needs-based evaluation does not prevent > those with need from getting addresses? It prevents those without > need from getting them.? > > > > Owen?s comment is absolutely false!!!!! It allows large > organizing who request resources to get what they need or > something smaller. It allows medium size organizations who > request resources to get what they need or something smaller. It > allows small organizations who request resources to get what they > need or nothing, and there is no other source to get resources if > ARIN rejects a request, but the open market which Owen and others > seem to wish did not exist! > > > > It is time to fix this inequity and removing needs tests would be > a big help to small organizations who really need resources! > > > > /Steven Ryerse/ > > /President/ > > /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ > > /770.656.1460 - Cell/ > > /770.399.9099- Office/ > > > > ? Eclipse Networks, Inc. > > ^ Conquering Complex Networks ^? > > > > *From:* arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Owen DeLong > *Sent:* Friday, September 25, 2015 1:24 PM > *To:* elvis at velea.eu > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of > IPv4 netblocks > > > > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: > > > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, > which makes me feel that it's not worth changing -- the > problem statement argument is weak at best. > > the outcome is that everyone that will need IP addresses will > be able to get them. Isn't that quite definitive and clear? > > > > Sure, except it isn?t actually an outcome of the proposal on many > levels: > > > > 1. The proposal does nothing to guarantee a supply of addresses or > even increase the supply. > > 2. To the extent that there is supply, anyone who needs addresses > can get them already. Needs-based evaluation does not prevent > those with need from getting addresses? It prevents those without > need from getting them. > > 3. The definitive outcome from the policy change, if there is > such, is that those without need will now be more easily able to > acquire addresses, potentially preventing those with need from > acquiring them. > > > > > It is potentially enabling organizations with more money > than need gain more resources, potentially at the expense > of non-profit and educational organizations who might not > be able to raise cash for additional IPv4 space [or > equipment to support a transition to IPv6]. > > So, you think that in today's market the > non-profit/educational organizations will have the chance at > getting some of the IP space from the market? And if the > needs-based barrier is removed, they will no longer have that > chance? > Everyone knows that the IP address is now an asset and is > worth a buck. Who do you think will say: I'll give it for free > to this educational organization (because they have proven the > need to ARIN) instead of giving it for money to this > commercial entity (that may or may not have a demonstrated > need need for it). > > > > Contrary to your statement, there have been addresses returned to > ARIN and there have been organizations who chose to transfer > addresses to those they found worthy rather than maximize the > monetization of those addresses. > > > > OTOH, having a policy like this in place certainly makes it easier > to manipulate the market to maximize the price. > > > > I think we need to wake up. Keeping needs-based criteria in > the policy will only cause SOME transfers to be driven > underground and block some others. > > > > I think claiming that those of us who believe needs-based criteria > is still useful are asleep is unwarranted. > > > > Changing policy just to (potentially) improve the accuracy > of a database seems not worth the (potential) risk. > > The change of the accuracy of the registry is already proven > in the RIPE region. I would say it's not just potential, it is > real and visible. > > > > Please provide the metrics on which you base this assertion. How > was RIPE-NCC accuracy measured prior to the policy change and to > what extent was it improved as a result of this policy change. > What mechanism was used to determine that the measured increase in > accuracy was the result of the particular policy abandoning > needs-based evaluation? > > > > Owen > > > > > Richard > > regards, > Elvis > > > ________________________________________ > From: arin-ppml-bounces at arin.net > > on behalf of Dani > Roisman > > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 > transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: > Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers > of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net > > > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, > and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for > Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of > 2015-9. I'd like to ask that in addition to any overall > support or lack thereof, you also review the policy > language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, > are there any refinements to the changes made which you > think will improve this should these policy changes be > implemented? > b) For those of you generally opposed to this effort, are > there any adjustments to the policy changes which, if > implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1468 bytes Desc: not available URL: From mike at iptrading.com Fri Sep 25 18:40:50 2015 From: mike at iptrading.com (Mike Burns) Date: Fri, 25 Sep 2015 18:40:50 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks References: <5605331E.30306@velea.eu><303C4CA8-78B4-4E1D-9ECF-3EF9EB7CF255@delong.com><22d7ed30e0c44bd7ae85c424aea092e3@eni-mail1.eclipse-networks.com> <5605C806.4010409@quark.net> Message-ID: The RIPE issue related directly to the price of IP addresses being doled out needs-free to each LIR. The price then was the fees paid to RIPE plus any fees incurred in creating the new LIR business entity. The net price was still far lower than the price for a /22 on the transfer market. It was the price difference that drove the policy work-arounds in RIPE. This is not an issue we face because our incentives are not misaligned. Because we know RIPE offers needs-free transfers, it was not the needs requirement that drove this practice. It was the profit incentive derived from policy conditions. Likewise here in North America policy conditions work to provide incentive for off-the-books transfers. As RIPE changed their policy to meet these real world conditions, ARIN should do the same and get rid of needs testing because it provides a disincentive for properly recording the transfer. Regards, Mike ----- Original Message ----- From: Andrew Dul To: arin-ppml at arin.net Sent: Friday, September 25, 2015 6:17 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks One might want to be reminded about what happened in the RIPE region when they allowed organizations to obtain /22 blocks by just opening a new LIR. There are lots of threads in the RIPE mailing-list that you can go read through if you desire. Here is a link to the outcome, a policy that restricts block flipping. https://www.ripe.net/participate/policies/proposals/2015-01 Yes, a /24 is not a /22, but if you decide that an organization can just come and get a free block, people will find ways to abuse the system. This doesn't apply in the ARIN region now, because our free pool is empty, but still we can see what happens when incentives are misaligned in resource allocation. Andrew On 9/25/2015 1:07 PM, Steven Ryerse wrote: So explain to me how anyone can corner the market on IPv4 blocks when they can only get one /24 per year without going thru your needs testing. They have to pay ARIN for them every year so in 3 years they can get up to 3 /24?s as long as they are willing to pay for them every year they have them. If they stop paying they lose the resources. This is a miniscule amount of resources, and I respectfully submit it would not appreciably change the availability of resources for anyone. It hasn?t in other regions as Elvis pointed out. It would however make a big difference to small Organizations and level the playing field. We are not far apart conceptually but we are far apart in what actually happens. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, September 25, 2015 3:46 PM To: Steven Ryerse Cc: Mike Winters ; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Your proposal was to allow anyone to get a /24 per year whether they needed anything or not. I am not opposed to a policy which would allow organizations with lesser need to obtain a minimum size block (/24 or /48) if the potential for abuse can be adequately addressed. By abuse, I mean, for example, the creation of entities with minimalist infrastructure strictly for the sake of qualifying for addresses. I?m all for the local bakery to be able to get a /24 to support their 3 cash registers, a router, and a few menu board displays. However, I?m not for VPNs-R-US being able to create 1024 entities each of which owns an SRX-100 and qualifies for a /24 on that basis. I don?t think resource policy should substantially change in a post-runout world and nothing said so far gives me any reason to believe there is benefit to the community from doing so. This isn't about miserly blocking of allocations for future theoretical use. This is about trying to make sure that organizations with need have the best chance of getting resources they need that we can provide. Allowing organizations without need to hoard addresses is contrary to that goal. Interestingly, we seem to have the same goal but radically different opinions on how best to achieve it. Owen On Sep 25, 2015, at 12:32 , Steven Ryerse wrote: I would probably agree with your comment that neither of the above really helps anyone and probably creates a host of other issues. I would probably not advocate them either but they would be more fair that the policies in place now. Of course the easy fix is to allow Organizations of any size to easily get the Minimum size block which I believe is now a /24 and that would go a long way towards fixing the problem. I put forth just that policy change proposal a while back with a limit of one block per year for small organizations and that Policy Proposal was summarily dumped by folks with Owen?s views. My preference is to allow organizations to more easily get resources in this post Run-Out world, rather than to somehow try to miserly block allocations in the hope of saving them for some unknown future use. I appreciate your attempt to be constructive. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: Mike Winters [mailto:mwinters at edwardrose.com] Sent: Friday, September 25, 2015 3:03 PM To: Steven Ryerse Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks That?s an interesting take on the ?inequity?? However, there is a fundamental flaw with your ?inequity? situation. If there is not enough addresses for a small organization to get them, then nobody would get them. They will eventually rise to the top just like everyone else, ergo no inequity. Assuming for a moment your argument is correct and not seriously flawed, then arguing that letting people who don?t need addresses get addresses is silly since it would only exacerbate the problem. It seems the best way to ?fix this inequity? that you describe would be to either: a) not let larger organizations accept smaller allocations; or b) make everyone take smaller allocations; or c) let ARIN allocate smaller blocks (really bad idea); or d) some crazy combination of the above Neither of the above really helps anyone and probably creates a host of other issues. To be clear, I am not advocating any of the above. Mike From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 1:48 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net on behalf of Dani Roisman Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ------------------------------------------------------------------------------ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1468 bytes Desc: not available URL: From owen at delong.com Fri Sep 25 20:03:59 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Sep 2015 17:03:59 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <22d7ed30e0c44bd7ae85c424aea092e3@eni-mail1.eclipse-networks.com> References: <5605331E.30306@velea.eu> <303C4CA8-78B4-4E1D-9ECF-3EF9EB7CF255@delong.com> <22d7ed30e0c44bd7ae85c424aea092e3@eni-mail1.eclipse-networks.com> Message-ID: > On Sep 25, 2015, at 13:07 , Steven Ryerse wrote: > > So explain to me how anyone can corner the market on IPv4 blocks when they can only get one /24 per year without going thru your needs testing. They have to pay ARIN for them every year so in 3 years they can get up to 3 /24?s as long as they are willing to pay for them every year they have them. If they stop paying they lose the resources. I never said your proposal allowed anyone to corner the market. It had no protection for related parties, so it would allow wide-scale abuse by entity creation. Additionally, I am opposed in principle to handing out addresses without need. I?m willing to substantially relax the definition of need and I can see need for a single /24 being ?I exist? just as I consider that valid need for a /48. However, once you want an additional /24 or an additional /48, you need to show how you?ve outgrown your existing address space. Note, a second physical location is, IMHO, sufficient for that. I?d support policy that codified things in this way? In fact, I helped write IPv6 policy that comes very close to this notion which is the current IPv6 policy. I wouldn?t be opposed to authorizing IPv4 transfers on a similar basis. > This is a miniscule amount of resources, and I respectfully submit it would not appreciably change the availability of resources for anyone. It hasn?t in other regions as Elvis pointed out. It would however make a big difference to small Organizations and level the playing field. Your policy was never adopted in ANY region, so that claim remains unproven. > We are not far apart conceptually but we are far apart in what actually happens. I don?t think we are as far apart as you claim. I?ve never encountered a small organization for whom I couldn?t find a legitimate way to justify an ARIN allocation or assignment (whichever was appropriate to the organization). I?ve handled a lot of requests for a lot of very small entities over the years. I?ve always found it more difficult to get a large amount of space for a large organization than to get a small amount of space for a small one. That?s why I have trouble believing your claims that need justification prevents people from getting addresses. Owen > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, September 25, 2015 3:46 PM > To: Steven Ryerse > Cc: Mike Winters ; arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > Your proposal was to allow anyone to get a /24 per year whether they needed anything or not. > > I am not opposed to a policy which would allow organizations with lesser need to obtain a minimum size block (/24 or /48) if the potential for abuse can be adequately addressed. > > By abuse, I mean, for example, the creation of entities with minimalist infrastructure strictly for the sake of qualifying for addresses. > > I?m all for the local bakery to be able to get a /24 to support their 3 cash registers, a router, and a few menu board displays. > > However, I?m not for VPNs-R-US being able to create 1024 entities each of which owns an SRX-100 and qualifies for a /24 on that basis. > > I don?t think resource policy should substantially change in a post-runout world and nothing said so far gives me any reason to believe there is benefit to the community from doing so. > > This isn't about miserly blocking of allocations for future theoretical use. This is about trying to make sure that organizations with need have the best chance of getting resources they need that we can provide. Allowing organizations without need to hoard addresses is contrary to that goal. > > Interestingly, we seem to have the same goal but radically different opinions on how best to achieve it. > > Owen > > On Sep 25, 2015, at 12:32 , Steven Ryerse > wrote: > > I would probably agree with your comment that neither of the above really helps anyone and probably creates a host of other issues. I would probably not advocate them either but they would be more fair that the policies in place now. > > Of course the easy fix is to allow Organizations of any size to easily get the Minimum size block which I believe is now a /24 and that would go a long way towards fixing the problem. I put forth just that policy change proposal a while back with a limit of one block per year for small organizations and that Policy Proposal was summarily dumped by folks with Owen?s views. > > My preference is to allow organizations to more easily get resources in this post Run-Out world, rather than to somehow try to miserly block allocations in the hope of saving them for some unknown future use. > > I appreciate your attempt to be constructive. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: Mike Winters [mailto:mwinters at edwardrose.com ] > Sent: Friday, September 25, 2015 3:03 PM > To: Steven Ryerse > > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > That?s an interesting take on the ?inequity?? > > However, there is a fundamental flaw with your ?inequity? situation. If there is not enough addresses for a small organization to get them, then nobody would get them. > They will eventually rise to the top just like everyone else, ergo no inequity. > > Assuming for a moment your argument is correct and not seriously flawed, then arguing that letting people who don?t need addresses get addresses is silly since it would only exacerbate the problem. > It seems the best way to ?fix this inequity? that you describe would be to either: > a) not let larger organizations accept smaller allocations; or > b) make everyone take smaller allocations; or > c) let ARIN allocate smaller blocks (really bad idea); or > d) some crazy combination of the above > > Neither of the above really helps anyone and probably creates a host of other issues. > To be clear, I am not advocating any of the above. > > Mike > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Steven Ryerse > Sent: Friday, September 25, 2015 1:48 PM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > Owens comment from below: > ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? > > Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! > > It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong > Sent: Friday, September 25, 2015 1:24 PM > To: elvis at velea.eu > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. > the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? > > Sure, except it isn?t actually an outcome of the proposal on many levels: > > 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. > 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. > 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. > > > > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. > So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? > Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). > > > Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. > > OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. > > > I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. > > I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. > > > Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. > The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. > > Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? > > Owen > > > > Richard > regards, > Elvis > > > ________________________________________ > From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net > > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Fri Sep 25 21:26:12 2015 From: bjones at vt.edu (Brian Jones) Date: Fri, 25 Sep 2015 21:26:12 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments In-Reply-To: References: <5589BC64.3070102@arin.net> <009f01d0afcf$a5633de0$f029b9a0$@giesen.me> <0BB2C211-E144-4FCF-877E-70A7843240A8@delong.com> Message-ID: I am in favor of this proposal. Relaxing the requirements could foster further IPv6 adoption. Brian Jones bjones at vt.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin at ics-il.net Fri Sep 25 23:48:05 2015 From: arin at ics-il.net (Mike Hammett) Date: Fri, 25 Sep 2015 22:48:05 -0500 (CDT) Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <56031175.5040102@arin.net> Message-ID: <153166379.11515.1443239340909.JavaMail.mhammett@ThunderFuck> Is this policy codifying that a /56 is the minimum acceptable assignment to an end-user and that if I assign less, I'm not allowed to come back to the IPv6 tough until I've filled up my space with whatever smaller than /56 allocations I decide to make? Not saying right or wrong, just seeking clarification. Maybe it's more appropriate under a different group than policy, but I'm new here, so this is the best spot I've seen so far (other than maybe ARIN-2015-1). Anything about X-Small ISPs and initial IPv6 allocations for them in the works? I know of many ISPs (personally, I know of dozens, though I'm sure several hundred of them exist in NA) that are X-small under IPv4 and don't have any IPv6 due to the added expense of moving up to small. yeah, it's not a large sum of money, but with increasing regulatory and network burdens, "bonus" areas like IPv6 are cast aside. Smaller blocks, smaller fees, I dunno, I'll let someone else figure out what's best there. Just trying to find ways of getting the little guys represented and brought into IPv6. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "ARIN" To: arin-ppml at arin.net Sent: Wednesday, September 23, 2015 3:54:13 PM Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments Draft Policy ARIN-2015-10 Minimum IPv6 Assignments On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy. Draft Policy ARIN-2015-10 is below and can be found at: https://www.arin.net/policy/proposals/2015_10.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-10 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2015-10 Minimum IPv6 Assignments Date: 23 September 2015 Problem Statement: ISPs may believe that they have an incentive to obtain smaller blocks than they really need, and once they receive their allocation may subsequently issue blocks smaller than their customers may need in the future. This policy seeks to encourage the correct behavior by reiterating the smallest reasonable sub-allocation size and by discounting any space which has been subdivided more finely from any future utilization analysis. Policy statement: Modify section 2.15 from "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48)." to "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites. A /48 is recommended as this smallest block size. In no case shall a provider assignment unit for the purpose of this policy be smaller than /56." Modify section 2.16.1 from "A provider assignment unit shall be considered fully utilized when it is assigned to an end-site" to "A provider assignment unit shall be considered fully utilized when it is assigned in full (or as part of a larger aggregate) to a single end-site. If a provider assignment unit (which shall be no smaller than /56) is split and assigned to multiple end-sites that entire provider assignment unit shall be considered NOT utilized." Comments: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Sep 26 03:18:56 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Sep 2015 00:18:56 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <153166379.11515.1443239340909.JavaMail.mhammett@ThunderFuck> References: <153166379.11515.1443239340909.JavaMail.mhammett@ThunderFuck> Message-ID: I suspect that is the intent, but as I read the policy, I believe the actual effect would be to cause the PAU to be counted as a /56 no matter how small a block you stuck your downstreams with. The current language already makes the PAU the smallest block you issue and requires you to justify all space issued to customers in units of that smallest size. The changes to 2.16.1 do seem to create a situation where allocations smaller than /56 cannot be counted for utilization at all. It also opens the flood gates for assigning multiple PAUs to a site without requiring any justification for the multiple PAUs vs. a single one. As such, I believe the text as written is actually contrary to solving the stated problem description is it allows (for example) an ISP to decide that their PAU is /56, issue /56s to customers that they want to treat as second-class citizens, and issue /48s to their higher paying customers without any additional justification for the larger blocks (or even something larger than a /48), thus eliminating the incentives codified into the original policy that require an ISP to treat all end-sites roughly the same or provide strong justification for the allocations and assignments that are larger than the smallest ones. I remain opposed to the policy on that basis. I would not be opposed to a policy which met the stated intent of this policy, but as currently written, I do not believe this proposal does so. Owen > On Sep 25, 2015, at 20:48 , Mike Hammett wrote: > > Is this policy codifying that a /56 is the minimum acceptable assignment to an end-user and that if I assign less, I'm not allowed to come back to the IPv6 tough until I've filled up my space with whatever smaller than /56 allocations I decide to make? Not saying right or wrong, just seeking clarification. > > Maybe it's more appropriate under a different group than policy, but I'm new here, so this is the best spot I've seen so far (other than maybe ARIN-2015-1). Anything about X-Small ISPs and initial IPv6 allocations for them in the works? I know of many ISPs (personally, I know of dozens, though I'm sure several hundred of them exist in NA) that are X-small under IPv4 and don't have any IPv6 due to the added expense of moving up to small. yeah, it's not a large sum of money, but with increasing regulatory and network burdens, "bonus" areas like IPv6 are cast aside. Smaller blocks, smaller fees, I dunno, I'll let someone else figure out what's best there. Just trying to find ways of getting the little guys represented and brought into IPv6. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > From: "ARIN" > To: arin-ppml at arin.net > Sent: Wednesday, September 23, 2015 3:54:13 PM > Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments > > Draft Policy ARIN-2015-10 > Minimum IPv6 Assignments > > On 17 September 2015 the ARIN Advisory Council (AC) accepted > "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy. > > Draft Policy ARIN-2015-10 is below and can be found at: > https://www.arin.net/policy/proposals/2015_10.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-10 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2015-10 > Minimum IPv6 Assignments > > Date: 23 September 2015 > > Problem Statement: > > ISPs may believe that they have an incentive to obtain smaller blocks > than they really need, and once they receive their allocation may > subsequently issue blocks smaller than their customers may need in the > future. This policy seeks to encourage the correct behavior by > reiterating the smallest reasonable sub-allocation size and by > discounting any space which has been subdivided more finely from any > future utilization analysis. > > Policy statement: > > Modify section 2.15 from "When applied to IPv6 policies, the term > "provider assignment unit" shall mean the prefix of the smallest block a > given ISP assigns to end sites (recommended /48)." to "When applied to > IPv6 policies, the term "provider assignment unit" shall mean the prefix > of the smallest block a given ISP assigns to end sites. A /48 is > recommended as this smallest block size. In no case shall a provider > assignment unit for the purpose of this policy be smaller than /56." > > Modify section 2.16.1 from "A provider assignment unit shall be > considered fully utilized when it is assigned to an end-site" to "A > provider assignment unit shall be considered fully utilized when it is > assigned in full (or as part of a larger aggregate) to a single > end-site. If a provider assignment unit (which shall be no smaller than > /56) is split and assigned to multiple end-sites that entire provider > assignment unit shall be considered NOT utilized." > > Comments: > 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. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 elvis at velea.eu Sat Sep 26 14:52:51 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Sat, 26 Sep 2015 21:52:51 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> <0742D43D-F93C-40EF-AAB0-7B061DE1E9C1@delong.com> <56052EC1.4080201@velea.eu> Message-ID: <5606E983.9090207@velea.eu> Hi Owen, On 25/09/15 21:56, Owen DeLong wrote: >> On Sep 25, 2015, at 04:23 , Elvis Daniel Velea wrote: >> >> Hi Owen, >> >> On 25/09/15 09:23, Owen DeLong wrote: >>> It?s not ARIN?s mission to prevent profits nor did I say it was. >>> >>> My point is that Elvis support for removing policy is strongly influenced by the potential windfall he stands to reap while not actually providing >>> any internet services in the process if the policy is changed as he wishes. >> Please stop implying what influences my beliefs. I doubt you can read my mind. >> >> I already said it several times that regardless of the outcome, there are plenty of organizations that have already received 'pre-approvals' and helping at least those will fill up my plate.. What do you mean we do not provide an internet service? We offer various services, not just the brokerage part. >>> As yo pointed out, many folks make a profit on various INETERNET SERVICES. Elvis, OTOH is not in the internet services business. He?s strictly >>> an address broker. >> What do you mean by 'not in the internet services business' ? I think you are starting to be rude and would like to ask you to back off a bit. >> We offer various services to our customers: IP management, LIR management, audits, Sponsoring LIR services (RIPE Region), IPv6 migration support, etc? > Do you offer any services involving moving bits between your clients and other organizations? so you are saying that only companies that move bits between customers/other organisations are in the internet service business? what about the RIRs? or the I* organizations ? I doubt they move bits for customers.. are they also excluded from your list or they do offer internet services? if the latter, what is then the difference? > > Or are you strictly in the address marketing/management business? > > From everything you have said to me, I?ve been led to believe the latter. If you actually sell access or transit services, hosting, or anything like that, then I stand corrected. we are discussing a policy change on the ARIN PPML list, not on nanog... and I am not even sure why you keep talking about this.. It really does not matter what the company I work for does, we are discussing here as citizens interested in the policies. > >>> It would be sort of like Realtors arguing against transfer taxes on real estate. An argument based solely in greed rather than any actual concern for the common good. >> Again, you are just guessing why I am commenting on this policy proposal. As an ex-RIR employee, I've told you (and others) several times that I still want to do the right thing for the community. I have already made several policy proposals in the RIPE Region (one recently accepted by the community) and I am active in APNIC and now ARIN? > Fair enough, but I?d call it an educated guess based on conversations we?ve had. I talk here in my name and not in the name of my company. Same as you and most of the people on this list. > >> Owen, last time we discussed you said that you understand the need of brokers and while a few years back you did not agree with us existing, now you are no longer against... I see personal attacks in the two e-mails you sent and I don't understand where these come from. > Not exactly. > > I said I understand the needs of brokers, not that I saw a need for brokers. Understanding the needs of brokers does not imply a desire to accommodate them. > I did say that I am not opposed to brokers existing and I am not. However, I?m not in favor of supporting them to the detriment of the community, either. > > In fact, I have worked with brokers to get IP addresses for organizations. I see no incompatibility between needs basis and brokers working above board. > > Your repeated expressions of willingness to conduct transfers outside the system if you can?t do whatever you want within the system are where I take exception. These have been your own words even in this very thread. I did not say that we will support transfers outside the system.. actually, this is our problem. Because we want to comply with the policy and because we do not close our eyes to potential customers violating the policies, we lose those potential customers. > > I?m sorry you see those as personal attacks. What I am attacking is the idea of contorting policy to suit the profit motives of an ancillary industry to the detriment of those actually building and operating infrastructure. I think you are looking at this from the wrong direction. I do want to have more customers and the removal of the needs based criteria will help. But you misunderstand the reasons behind it. I have repeated them several times already... If a potential buyer has the money and wants to buy the resource (in order to use them, or keep them for a few years - maybe they want to make sure that they will never run out) they will buy them.. through financial artifices if they can not do it through the brokers and with ARIN's blessing. > > It was never my intent to attack you personally. I did take it personally, "Elvis, OTOH is not in the internet services business." - how would you call that? > >> Owen, please stop guessing what my business does and why I participate in the discussions. I doubt this is what an ARIN AC member should do.. > I didn?t think I was guessing what your business did. Everything I said was based on what you told me your business did. I?m sorry if I misunderstood or got it wrong. I think you have a strange way to classify internet services and the businesses offering these services. You seem to include only ISPs and hosting companies in this category, while I think that all companies offering various services to the internet 'actors' should be included. Whether these services are offered by non-for-profit (RIRs, ISTARs, etc) or for-profit (brokers, consultants, some research companies, etc), these are services that - from my point of view - are part of the internet services businesses. > > I will make clear that my posts here are as a member of the community and not in any official capacity as a member of the AC. thank you for clarifying that. I was surprised to see an AC member so passionate to combat a policy proposal shepherd by other AC member(s). > > Owen > > cheers, elvis From elvis at velea.eu Sat Sep 26 15:11:56 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Sat, 26 Sep 2015 22:11:56 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: <5606EDFC.4090401@velea.eu> Owen, On 25/09/15 20:24, Owen DeLong wrote: > Please provide the metrics on which you base this assertion. How was > RIPE-NCC accuracy measured prior to the policy change and to what > extent was it improved as a result of this policy change. What > mechanism was used to determine that the measured increase in accuracy > was the result of the particular policy abandoning needs-based evaluation? > just have a look at the number of transfers pre-2013-03 and the number of transfers after the policy proposal was implemented. Basically, transfers via the RIPE NCC (recorded in the registry) have become the standard for everyone in the RIPE region, financial artifices have not been used anymore (as far as I know) once the need-based barrier has been removed. cheers, elvis From elvis at velea.eu Sat Sep 26 15:14:31 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Sat, 26 Sep 2015 22:14:31 +0300 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> <0742D43D-F93C-40EF-AAB0-7B061DE1E9C1@delong.com> <56052EC1.4080201@velea.eu> Message-ID: <5606EE97.2090201@velea.eu> One more thing regarding the moving bits businesses.. On 25/09/15 21:56, Owen DeLong wrote: > Do you offer any services involving moving bits between your clients > and other organizations? Or are you strictly in the address > marketing/management business? From everything you have said to me, > I?ve been led to believe the latter. If you actually sell access or > transit services, hosting, or anything like that, then I stand corrected. the fact that service providers are willing to route blocks which are not reflected in the registry indicates (at some level) support for more transfer-friendly policies, even if they are not advocating for changes on this list... my 2 cents, elvis From andrew.dul at quark.net Sat Sep 26 18:20:21 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Sat, 26 Sep 2015 15:20:21 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <5606EDFC.4090401@velea.eu> References: <5605331E.30306@velea.eu> <5606EDFC.4090401@velea.eu> Message-ID: <56071A25.7000700@quark.net> On 9/26/2015 12:11 PM, Elvis Daniel Velea wrote: > Owen, > > On 25/09/15 20:24, Owen DeLong wrote: >> Please provide the metrics on which you base this assertion. How was >> RIPE-NCC accuracy measured prior to the policy change and to what >> extent was it improved as a result of this policy change. What >> mechanism was used to determine that the measured increase in >> accuracy was the result of the particular policy abandoning >> needs-based evaluation? >> > just have a look at the number of transfers pre-2013-03 and the number > of transfers after the policy proposal was implemented. > > Basically, transfers via the RIPE NCC (recorded in the registry) have > become the standard for everyone in the RIPE region, financial > artifices have not been used anymore (as far as I know) once the > need-based barrier has been removed. > Just because there are more transfers, one cannot know for sure that the data is more accurate. The number of transfers may be increasing for other reasons. It is possible that the data is more accurate, but just saying "see there are more transfers" does not mean the database is more accurate. Andrew From mpetach at netflight.com Sat Sep 26 20:07:20 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 26 Sep 2015 17:07:20 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <56031175.5040102@arin.net> References: <56031175.5040102@arin.net> Message-ID: OPPOSED How I subdivide and allocate addresses internally and downstream is not a matter for the community to vote on; that's between me and my customers. Matt On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: > Draft Policy ARIN-2015-10 > Minimum IPv6 Assignments > > On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 > Minimum IPv6 Assignments" as a Draft Policy. > > Draft Policy ARIN-2015-10 is below and can be found at: > https://www.arin.net/policy/proposals/2015_10.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-10 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2015-10 > Minimum IPv6 Assignments > > Date: 23 September 2015 > > Problem Statement: > > ISPs may believe that they have an incentive to obtain smaller blocks than > they really need, and once they receive their allocation may subsequently > issue blocks smaller than their customers may need in the future. This > policy seeks to encourage the correct behavior by reiterating the smallest > reasonable sub-allocation size and by discounting any space which has been > subdivided more finely from any future utilization analysis. > > Policy statement: > > Modify section 2.15 from "When applied to IPv6 policies, the term "provider > assignment unit" shall mean the prefix of the smallest block a given ISP > assigns to end sites (recommended /48)." to "When applied to IPv6 policies, > the term "provider assignment unit" shall mean the prefix of the smallest > block a given ISP assigns to end sites. A /48 is recommended as this > smallest block size. In no case shall a provider assignment unit for the > purpose of this policy be smaller than /56." > > Modify section 2.16.1 from "A provider assignment unit shall be considered > fully utilized when it is assigned to an end-site" to "A provider assignment > unit shall be considered fully utilized when it is assigned in full (or as > part of a larger aggregate) to a single end-site. If a provider assignment > unit (which shall be no smaller than /56) is split and assigned to multiple > end-sites that entire provider assignment unit shall be considered NOT > utilized." > > Comments: > 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 bjones at vt.edu Sat Sep 26 21:31:18 2015 From: bjones at vt.edu (Brian Jones) Date: Sat, 26 Sep 2015 21:31:18 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> Message-ID: I do not think this policy is unsound or unfair, however I do not believe it will have the intended effect. Network Operators should have the ability to subnet their address blocks as they see fit without being penalized when they come back for more addresses. It seems that as long as the allocated space has been utilized they should be able to successfully request more. I agree that a /48 makes reasonable sense as an assignment block size for end sites. It also makes more sense to limit the number of smaller routed block sizes to keep Internet routing tables from unreasonable growth. -- Brian On Thu, Sep 24, 2015 at 3:37 PM, John Springer wrote: > Hi PPML, > > There have been a number of public discussions regarding the ins and outs > of IPV6 subnet allocation. One such starts here: > http://mailman.nanog.org/pipermail/nanog/2014-October/070339.html > > My recollection of the outcomes of these discussions is a sort of rough > consensus that /48 is a good idea and indeed, many of the calculations used > to evaluate what size of V6 block an org should request, start with that > assumtion. > > ARIN (speaking as myself, not a member of any group and roughly > paraphrasing someone more authoritative than I) does not dictate what you > do with addresses after the allocation has been received. In some cases, > ARIN looks at what you do with addresses when you come back for more and > might not give them to you depending on what choices you have made. > > That is what this Draft Proposal seeks to do. > > I think it is clear that we can do that. Should we? > > And if you have an opinion of no, are you able to say because it is > technically unsound or unfair and partial? > > John Springer > > > On Wed, 23 Sep 2015, ARIN wrote: > > Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> On 17 September 2015 the ARIN Advisory Council (AC) accepted >> "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy. >> >> Draft Policy ARIN-2015-10 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_10.html >> >> You are encouraged to discuss the merits and your concerns of Draft >> Policy 2015-10 on the Public Policy Mailing List. >> >> The AC will evaluate the discussion in order to assess the conformance >> of this draft policy with ARIN's Principles of Internet Number Resource >> Policy as stated in the PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (PDP) can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> Date: 23 September 2015 >> >> Problem Statement: >> >> ISPs may believe that they have an incentive to obtain smaller blocks >> than they really need, and once they receive their allocation may >> subsequently issue blocks smaller than their customers may need in the >> future. This policy seeks to encourage the correct behavior by reiterating >> the smallest reasonable sub-allocation size and by discounting any space >> which has been subdivided more finely from any future utilization analysis. >> >> Policy statement: >> >> Modify section 2.15 from "When applied to IPv6 policies, the term >> "provider assignment unit" shall mean the prefix of the smallest block a >> given ISP assigns to end sites (recommended /48)." to "When applied to IPv6 >> policies, the term "provider assignment unit" shall mean the prefix of the >> smallest block a given ISP assigns to end sites. A /48 is recommended as >> this smallest block size. In no case shall a provider assignment unit for >> the purpose of this policy be smaller than /56." >> >> Modify section 2.16.1 from "A provider assignment unit shall be >> considered fully utilized when it is assigned to an end-site" to "A >> provider assignment unit shall be considered fully utilized when it is >> assigned in full (or as part of a larger aggregate) to a single end-site. >> If a provider assignment unit (which shall be no smaller than /56) is split >> and assigned to multiple end-sites that entire provider assignment unit >> shall be considered NOT utilized." >> >> Comments: >> 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. >> >> >> _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Sat Sep 26 21:47:46 2015 From: bjones at vt.edu (Brian Jones) Date: Sat, 26 Sep 2015 21:47:46 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. -- Brian On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler wrote: > Having watched this for the last couple of years let me make a couple of > observations / one proposal: > > > > There seems to be a lot of fear on both sides of this debate, on the needs > test side there seems to be a complete fear of monopolization of the IP > address space by those with deep pockets. > > > > On the other side there seem to be a couple of thoughts: > > > > 1. It?s a market, markets work best when freed from constraints > that increase the complexity of non-harmful transactions, and that allowing > companies to more freely exchange IP resources is not harmful. > > 2. Not liking to justify future and current operations to a third > party / fear of rejection by this process. > > > > I may not have encapsulated both arguments well, and these have been > hashed over again and again for the last few years. So what is different > today? ARIN has allocated every last resource from the free pool, and has a > long waiting list. > > > > So what if we strike a compromise? What if some restrictions were put on > allocation size and frequency without a needs test and left only the truly > large or frequent transactions to do it. Something like this: > > > > Every legal entity can obtain up to a /22 from the transfer market every > year, in up to two transactions. They may not transfer these resources out > of their network within twelve months. Each legal entity has to occupy a > unique address (suite level) from any other entity in the ARIN database. > > > > All transfers larger than a /22 need to have needs based justification > done based on the current model. > > > > > > If you wanted to speculate, you would need to spin-up dozens of entities > all with unique mailstops, and you would have to camp on the addresses for > a year. Meanwhile the small end users and ISPs could obtain up to a /22 of > a resource that with a lot of careful use of NAT would support a fairly > large public network. > > > > Best regards, > > > > Bill Buhler > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Steven Ryerse > *Sent:* Friday, September 25, 2015 11:48 AM > *To:* Owen DeLong > > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 > netblocks > > > > Owens comment from below: > > ?2. To the extent that there is supply, anyone who needs addresses can get > them already. Needs-based evaluation does not prevent those with need from > getting addresses? It prevents those without need from getting them.? > > > > Owen?s comment is absolutely false!!!!! It allows large organizing who > request resources to get what they need or something smaller. It allows > medium size organizations who request resources to get what they need or > something smaller. It allows small organizations who request resources to > get what they need or nothing, and there is no other source to get > resources if ARIN rejects a request, but the open market which Owen and > others seem to wish did not exist! > > > > It is time to fix this inequity and removing needs tests would be a big > help to small organizations who really need resources! > > > > *Steven Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 <770.656.1460> - Cell* > > *770.399.9099 <770.399.9099>- Office* > > > > [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse > Networks, Inc. > > Conquering Complex Networks? > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *Owen DeLong > *Sent:* Friday, September 25, 2015 1:24 PM > *To:* elvis at velea.eu > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 > netblocks > > > > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea wrote: > > > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel > that it's not worth changing -- the problem statement argument is weak at > best. > > the outcome is that everyone that will need IP addresses will be able to > get them. Isn't that quite definitive and clear? > > > > Sure, except it isn?t actually an outcome of the proposal on many levels: > > > > 1. The proposal does nothing to guarantee a supply of addresses or even > increase the supply. > > 2. To the extent that there is supply, anyone who needs addresses can get > them already. Needs-based evaluation does not prevent those with need from > getting addresses? It prevents those without need from getting them. > > 3. The definitive outcome from the policy change, if there is such, is > that those without need will now be more easily able to acquire addresses, > potentially preventing those with need from acquiring them. > > > > > It is potentially enabling organizations with more money than need gain > more resources, potentially at the expense of non-profit and educational > organizations who might not be able to raise cash for additional IPv4 space > [or equipment to support a transition to IPv6]. > > So, you think that in today's market the non-profit/educational > organizations will have the chance at getting some of the IP space from the > market? And if the needs-based barrier is removed, they will no longer have > that chance? > Everyone knows that the IP address is now an asset and is worth a buck. > Who do you think will say: I'll give it for free to this educational > organization (because they have proven the need to ARIN) instead of giving > it for money to this commercial entity (that may or may not have a > demonstrated need need for it). > > > > Contrary to your statement, there have been addresses returned to ARIN and > there have been organizations who chose to transfer addresses to those they > found worthy rather than maximize the monetization of those addresses. > > > > OTOH, having a policy like this in place certainly makes it easier to > manipulate the market to maximize the price. > > > > I think we need to wake up. Keeping needs-based criteria in the policy > will only cause SOME transfers to be driven underground and block some > others. > > > > I think claiming that those of us who believe needs-based criteria is > still useful are asleep is unwarranted. > > > > Changing policy just to (potentially) improve the accuracy of a database > seems not worth the (potential) risk. > > The change of the accuracy of the registry is already proven in the RIPE > region. I would say it's not just potential, it is real and visible. > > > > Please provide the metrics on which you base this assertion. How was > RIPE-NCC accuracy measured prior to the policy change and to what extent > was it improved as a result of this policy change. What mechanism was used > to determine that the measured increase in accuracy was the result of the > particular policy abandoning needs-based evaluation? > > > > Owen > > > > > Richard > > regards, > Elvis > > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf > of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 > netblocks > | Message-ID: <56031167.1010007 at arin.net> > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd > like to ask that in addition to any overall support or lack thereof, you > also review the policy language and comment specifically on the changes > proposed: > a) For those of you generally in support of this effort, are there any > refinements to the changes made which you think will improve this should > these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any > adjustments to the policy changes which, if implemented, would gain your > support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: not available URL: From athompso at athompso.net Sat Sep 26 22:48:05 2015 From: athompso at athompso.net (Adam Thompson) Date: Sat, 26 Sep 2015 21:48:05 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> Message-ID: <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. -Adam On September 26, 2015 8:47:46 PM CDT, Brian Jones wrote: >I find Bill's proposal an interesting middle ground approach. I do not >believe completely eliminating needs-based justification for addresses >is >the correct thing to do. > >-- >Brian > >On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler wrote: > >> Having watched this for the last couple of years let me make a couple >of >> observations / one proposal: >> >> >> >> There seems to be a lot of fear on both sides of this debate, on the >needs >> test side there seems to be a complete fear of monopolization of the >IP >> address space by those with deep pockets. >> >> >> >> On the other side there seem to be a couple of thoughts: >> >> >> >> 1. It?s a market, markets work best when freed from constraints >> that increase the complexity of non-harmful transactions, and that >allowing >> companies to more freely exchange IP resources is not harmful. >> >> 2. Not liking to justify future and current operations to a >third >> party / fear of rejection by this process. >> >> >> >> I may not have encapsulated both arguments well, and these have been >> hashed over again and again for the last few years. So what is >different >> today? ARIN has allocated every last resource from the free pool, and >has a >> long waiting list. >> >> >> >> So what if we strike a compromise? What if some restrictions were put >on >> allocation size and frequency without a needs test and left only the >truly >> large or frequent transactions to do it. Something like this: >> >> >> >> Every legal entity can obtain up to a /22 from the transfer market >every >> year, in up to two transactions. They may not transfer these >resources out >> of their network within twelve months. Each legal entity has to >occupy a >> unique address (suite level) from any other entity in the ARIN >database. >> >> >> >> All transfers larger than a /22 need to have needs based >justification >> done based on the current model. >> >> >> >> >> >> If you wanted to speculate, you would need to spin-up dozens of >entities >> all with unique mailstops, and you would have to camp on the >addresses for >> a year. Meanwhile the small end users and ISPs could obtain up to a >/22 of >> a resource that with a lot of careful use of NAT would support a >fairly >> large public network. >> >> >> >> Best regards, >> >> >> >> Bill Buhler >> >> >> >> *From:* arin-ppml-bounces at arin.net >[mailto:arin-ppml-bounces at arin.net] *On >> Behalf Of *Steven Ryerse >> *Sent:* Friday, September 25, 2015 11:48 AM >> *To:* Owen DeLong >> >> *Cc:* arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >> needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of >IPv4 >> netblocks >> >> >> >> Owens comment from below: >> >> ?2. To the extent that there is supply, anyone who needs addresses >can get >> them already. Needs-based evaluation does not prevent those with need >from >> getting addresses? It prevents those without need from getting them.? >> >> >> >> Owen?s comment is absolutely false!!!!! It allows large organizing >who >> request resources to get what they need or something smaller. It >allows >> medium size organizations who request resources to get what they need >or >> something smaller. It allows small organizations who request >resources to >> get what they need or nothing, and there is no other source to get >> resources if ARIN rejects a request, but the open market which Owen >and >> others seem to wish did not exist! >> >> >> >> It is time to fix this inequity and removing needs tests would be a >big >> help to small organizations who really need resources! >> >> >> >> *Steven Ryerse* >> >> *President* >> >> *100 Ashford Center North, Suite 110, Atlanta, GA 30338* >> >> *770.656.1460 <770.656.1460> - Cell* >> >> *770.399.9099 <770.399.9099>- Office* >> >> >> >> [image: Description: Description: Eclipse Networks Logo_small.png]? >Eclipse >> Networks, Inc. >> >> Conquering Complex Networks? >> >> >> >> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >> ] *On Behalf Of *Owen DeLong >> *Sent:* Friday, September 25, 2015 1:24 PM >> *To:* elvis at velea.eu >> *Cc:* arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >> needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of >IPv4 >> netblocks >> >> >> >> >> >> On Sep 25, 2015, at 04:42 , Elvis Daniel Velea >wrote: >> >> >> >> Hi Richard, >> >> On 25/09/15 06:46, Richard J. Letts wrote: >> >> b) >> There is no definitive outcome from the policy change, which makes me >feel >> that it's not worth changing -- the problem statement argument is >weak at >> best. >> >> the outcome is that everyone that will need IP addresses will be able >to >> get them. Isn't that quite definitive and clear? >> >> >> >> Sure, except it isn?t actually an outcome of the proposal on many >levels: >> >> >> >> 1. The proposal does nothing to guarantee a supply of addresses or >even >> increase the supply. >> >> 2. To the extent that there is supply, anyone who needs addresses can >get >> them already. Needs-based evaluation does not prevent those with need >from >> getting addresses? It prevents those without need from getting them. >> >> 3. The definitive outcome from the policy change, if there is such, >is >> that those without need will now be more easily able to acquire >addresses, >> potentially preventing those with need from acquiring them. >> >> >> >> >> It is potentially enabling organizations with more money than need >gain >> more resources, potentially at the expense of non-profit and >educational >> organizations who might not be able to raise cash for additional IPv4 >space >> [or equipment to support a transition to IPv6]. >> >> So, you think that in today's market the non-profit/educational >> organizations will have the chance at getting some of the IP space >from the >> market? And if the needs-based barrier is removed, they will no >longer have >> that chance? >> Everyone knows that the IP address is now an asset and is worth a >buck. >> Who do you think will say: I'll give it for free to this educational >> organization (because they have proven the need to ARIN) instead of >giving >> it for money to this commercial entity (that may or may not have a >> demonstrated need need for it). >> >> >> >> Contrary to your statement, there have been addresses returned to >ARIN and >> there have been organizations who chose to transfer addresses to >those they >> found worthy rather than maximize the monetization of those >addresses. >> >> >> >> OTOH, having a policy like this in place certainly makes it easier to >> manipulate the market to maximize the price. >> >> >> >> I think we need to wake up. Keeping needs-based criteria in the >policy >> will only cause SOME transfers to be driven underground and block >some >> others. >> >> >> >> I think claiming that those of us who believe needs-based criteria is >> still useful are asleep is unwarranted. >> >> >> >> Changing policy just to (potentially) improve the accuracy of a >database >> seems not worth the (potential) risk. >> >> The change of the accuracy of the registry is already proven in the >RIPE >> region. I would say it's not just potential, it is real and visible. >> >> >> >> Please provide the metrics on which you base this assertion. How was >> RIPE-NCC accuracy measured prior to the policy change and to what >extent >> was it improved as a result of this policy change. What mechanism was >used >> to determine that the measured increase in accuracy was the result of >the >> particular policy abandoning needs-based evaluation? >> >> >> >> Owen >> >> >> >> >> Richard >> >> regards, >> Elvis >> >> >> ________________________________________ >> From: arin-ppml-bounces at arin.net on >behalf >> of Dani Roisman >> Sent: Thursday, September 24, 2015 6:20 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >needs-based >> evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> | Date: Wed, 23 Sep 2015 16:53:59 -0400 >> | From: ARIN >> | To: arin-ppml at arin.net >> | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >needs-based >> | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 >> netblocks >> | Message-ID: <56031167.1010007 at arin.net> >> | Content-Type: text/plain; charset=utf-8; format=flowed >> | >> | Draft Policy ARIN-2015-9 >> | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >> | transfers of IPv4 netblocks >> | >> | On 17 September 2015 the ARIN Advisory Council (AC) accepted >> | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, >8.3, >> | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >> | >> | Draft Policy ARIN-2015-9 is below and can be found at: >> | https://www.arin.net/policy/proposals/2015_9.html >> >> Greetings, >> >> There has been some stimulating dialog about the merits of 2015-9. >I'd >> like to ask that in addition to any overall support or lack thereof, >you >> also review the policy language and comment specifically on the >changes >> proposed: >> a) For those of you generally in support of this effort, are there >any >> refinements to the changes made which you think will improve this >should >> these policy changes be implemented? >> b) For those of you generally opposed to this effort, are there any >> adjustments to the policy changes which, if implemented, would gain >your >> support? >> >> -- >> Dani Roisman >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > >------------------------------------------------------------------------ > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpetach at netflight.com Sat Sep 26 23:00:00 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 26 Sep 2015 20:00:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: I am OPPOSED to the proposal as written; I think it's a bridge too far. I would instead support a compromise as has been discussed of a total of one /22 per year per org-ID transferrable needs-free; I would recommend the hold period be two years from transfer date (ie, you may not transfer that block of addresses again for 24 months so long as you remain a solvent business entity; if you become insolvent, ARIN can arm wrestle with the court over control of the number resource). Any transfer larger than a /22 would still be subject to need analysis. Matt On Thu, Sep 24, 2015 at 6:20 PM, Dani Roisman wrote: > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net> > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 eu at smellmysocks.net Sun Sep 27 06:23:16 2015 From: eu at smellmysocks.net (Radu Anghel) Date: Sun, 27 Sep 2015 12:23:16 +0200 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <5606EE97.2090201@velea.eu> References: <56031167.1010007@arin.net> <56045947.9070201@velea.eu> <5179CA52-4BBD-4DD7-BE30-4C56E3E9C247@delong.com> <1d8e1e0adb24420dac4b09c5e3bdde87@eni-mail1.eclipse-networks.com> <0742D43D-F93C-40EF-AAB0-7B061DE1E9C1@delong.com> <56052EC1.4080201@velea.eu> <5606EE97.2090201@velea.eu> Message-ID: On Sat, Sep 26, 2015 at 9:14 PM, Elvis Daniel Velea wrote: > One more thing regarding the moving bits businesses.. > > the fact that service providers are willing to route blocks which are not > reflected in the registry indicates (at some level) support for more > transfer-friendly policies, even if they are not advocating for changes on > this list... > > my 2 cents, > elvis In my opinion routing blocks that are not properly registered in IRRs isn't advocating for anything, it might be a sign of clueless/careless SP or a bad guy in sheep's clothes. At most, if they really must be advocating something, it's probably RPKI and similar stuff. On the same logic I might say that because some people steal they are indirectly in support for more theft-friendly laws, even if they don't state their wishes directly to the law makers. +0.02 EUR ;) Radu From mpetach at netflight.com Sun Sep 27 13:46:05 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 27 Sep 2015 10:46:05 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments In-Reply-To: References: <5589BC64.3070102@arin.net> <009f01d0afcf$a5633de0$f029b9a0$@giesen.me> Message-ID: On Fri, Jun 26, 2015 at 3:22 PM, William Herrin wrote: > > Maybe there's a third way we're not seeing, like retiring e, adding > the new element as f, and then re-inserting the catchall some other > way, point g or as a sentence that follows the ordered list. Oooh, I like that--remove the catch-all from the ordered list, and make it a separate sentence after the list: "Finally, an organization may also qualify by providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable." I'd support this proposal with the catch-all moved to a separate sentence after the list, and the list item lettering being kept consistent before and after the change for all other list items. Matt > > Regards, > Bill > From stephen at sprunk.org Sun Sep 27 17:10:05 2015 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 27 Sep 2015 16:10:05 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> <56059FB1.8000808@sprunk.org> Message-ID: <56085B2D.6000003@sprunk.org> On 25-Sep-15 14:33, Steven Ryerse wrote: > Stephen Sprunk on Friday, September 25, 2015 3:26: >> On 25-Sep-15 12:48, Steven Ryerse wrote: >>> It is time to fix this inequity and removing needs tests would be >>> a big help to small organizations who really need resources! >> >> If they actually need the resources, then a needs-based policy >> does not present an obstacle. Where's the problem? >> >> However, not having such a policy will mean that folks who _don't_ >> need resources can also get them, which makes the (IPv4) scarcity >> problem even worse than it already is. That benefits speculators >> at the expense of those who actually need resources. >> >> You appear to be arguing against your stated interests. > > It appears to me that you are still trying to somehow save IPv4 from > exhaustion. That horse is out of the barn and gone. My comments above merely point out that your justification does not support your proposed action: if organizations actually need resources, then a needs-based policy is not an obstacle, so removing such will not help them and may, in fact, hurt them. It is certainly possible that current needs-based policy sets the bar too high, e.g. the minimum block size is too large. If so, then the proper action would be improving that policy, e.g. by reducing the minimum block size, rather than throwing it away entirely. 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2414 bytes Desc: S/MIME Cryptographic Signature URL: From jrdelacruz at acm.org Mon Sep 28 06:22:03 2015 From: jrdelacruz at acm.org (Jose R. de la Cruz III) Date: Mon, 28 Sep 2015 06:22:03 -0400 Subject: [arin-ppml] Fwd: Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <56031167.1010007@arin.net> <12729e54a9ef44a8bddf05036b66c5ab@eni-mail1.eclipse-networks.com> <56045441.2040106@velea.eu> Message-ID: ---------- Forwarded message ---------- From: Jose R. de la Cruz III Date: Sun, Sep 27, 2015 at 10:18 AM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks To: John Curran Hi John. This is my first post, so please excuse my ignorance. It seems that the main problem is maintaining an accurate registry. My question to you is, can the registry be 'updated' in the sense of adding additional fields to show the 'legal' owner, plus the actual organization using the addresses? Just a thought, but maybe keeping track of organizations that only request address blocks to immediately transfer them out would become an indicator of such organization's real need. Further allocations would also take into account this fact, as the community will be aware of the real need. Jos? On Thu, Sep 24, 2015 at 4:16 PM, John Curran wrote: > On Sep 24, 2015, at 3:51 PM, Elvis Daniel Velea wrote: > > > > +1 > > > > Keeping needs basis in the NRPM will only drive the transfers > underground. Some are already using all kind of financial tricks (futures > contracts, lease contracts, etc) and are waiting for the needs basis > criteria to be removed from NRPM in order to register the transfers in the > ARIN Registry. > > > > The Registry/Whois will win most from the removal of needs basis from > the NRPM and process streamlining. > > Elvis - > > To be clear, there is nothing ?improper? about a future or option > contract if two > private parties decide to engage in such (and I can imagine cases where > such > an arrangement might make sense regardless of state of IPv4 transfer > policy.) > > This does not detract from the your point that the usefulness of the > registry is > maximum when the party actually using the address block is the > registrant > (and hence transfer policies which even indirectly encourage other > outcomes > reduce its functionality, e.g. for operations, etc.) > > There are even cases where loaning/leasing of address blocks may make > sense; > I believe your point is that we don?t want to see these sorts of > arrangements appear > (in circumstances beyond their normal useful roles) as alternatives to > transfers > simply as a result of transfer policy hurdles - is that correct? > > Thanks, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From springer at inlandnet.com Mon Sep 28 11:35:42 2015 From: springer at inlandnet.com (John Springer) Date: Mon, 28 Sep 2015 08:35:42 -0700 (PDT) Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> Message-ID: Thanks, Matt This is precisely the subject on which I hoped to get community feedback. John Springer On Sat, 26 Sep 2015, Matthew Petach wrote: > OPPOSED > > How I subdivide and allocate addresses > internally and downstream is not a matter > for the community to vote on; that's between > me and my customers. > > Matt > > > On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >> Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 >> Minimum IPv6 Assignments" as a Draft Policy. >> >> Draft Policy ARIN-2015-10 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_10.html >> >> You are encouraged to discuss the merits and your concerns of Draft >> Policy 2015-10 on the Public Policy Mailing List. >> >> The AC will evaluate the discussion in order to assess the conformance >> of this draft policy with ARIN's Principles of Internet Number Resource >> Policy as stated in the PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (PDP) can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy ARIN-2015-10 >> Minimum IPv6 Assignments >> >> Date: 23 September 2015 >> >> Problem Statement: >> >> ISPs may believe that they have an incentive to obtain smaller blocks than >> they really need, and once they receive their allocation may subsequently >> issue blocks smaller than their customers may need in the future. This >> policy seeks to encourage the correct behavior by reiterating the smallest >> reasonable sub-allocation size and by discounting any space which has been >> subdivided more finely from any future utilization analysis. >> >> Policy statement: >> >> Modify section 2.15 from "When applied to IPv6 policies, the term "provider >> assignment unit" shall mean the prefix of the smallest block a given ISP >> assigns to end sites (recommended /48)." to "When applied to IPv6 policies, >> the term "provider assignment unit" shall mean the prefix of the smallest >> block a given ISP assigns to end sites. A /48 is recommended as this >> smallest block size. In no case shall a provider assignment unit for the >> purpose of this policy be smaller than /56." >> >> Modify section 2.16.1 from "A provider assignment unit shall be considered >> fully utilized when it is assigned to an end-site" to "A provider assignment >> unit shall be considered fully utilized when it is assigned in full (or as >> part of a larger aggregate) to a single end-site. If a provider assignment >> unit (which shall be no smaller than /56) is split and assigned to multiple >> end-sites that entire provider assignment unit shall be considered NOT >> utilized." >> >> Comments: >> 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. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From owen at delong.com Mon Sep 28 13:11:13 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Sep 2015 10:11:13 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> References: <5605331E.30306@velea.eu> <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> Message-ID: <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> I?m not going to support anything that provides a blanket exemption from needs basis. I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). Owen > On Sep 26, 2015, at 19:48 , Adam Thompson wrote: > > At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). > Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. > -Adam > > > On September 26, 2015 8:47:46 PM CDT, Brian Jones wrote: > I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. > > -- > Brian > > On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler > wrote: > Having watched this for the last couple of years let me make a couple of observations / one proposal: > > > > There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. > > > > On the other side there seem to be a couple of thoughts: > > > > 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. > > 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. > > > > I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. > > > > So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: > > > > Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. > > > > All transfers larger than a /22 need to have needs based justification done based on the current model. > > > > > > If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. > > > > Best regards, > > > > Bill Buhler > > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Steven Ryerse > Sent: Friday, September 25, 2015 11:48 AM > To: Owen DeLong > > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > > Owens comment from below: > > ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? > > > > Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! > > > > It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! > > > > Steven Ryerse > > President > > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > > 770.656.1460 - Cell > > 770.399.9099 - Office > > > > ? Eclipse Networks, Inc. > > Conquering Complex Networks? > > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong > Sent: Friday, September 25, 2015 1:24 PM > To: elvis at velea.eu > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: > > > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. > > the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? > > > > Sure, except it isn?t actually an outcome of the proposal on many levels: > > > > 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. > > 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. > > 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. > > > > > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. > > So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? > Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). > > > > Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. > > > > OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. > > > > I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. > > > > I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. > > > > Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. > > The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. > > > > Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? > > > > Owen > > > > > Richard > > regards, > Elvis > > > ________________________________________ > From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net > > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Mon Sep 28 14:50:55 2015 From: bill at tknow.com (Bill Buhler) Date: Mon, 28 Sep 2015 18:50:55 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> References: <5605331E.30306@velea.eu> <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> Message-ID: <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> Thanks Owen for your thoughts, it sounds to me like we are getting a lot closer to a compromise, would this be a sufficient circuit breaker: Small end users and ISPs are allowed initial and follow up transfers up to a /20 for ISPs or /22 for end users from the market. These transfers can be conducted in no more than three operations over a 24 month period. None of the transferred addresses can be transferred to another entity for twenty-four months following the date of the last transfer. If the company ceases operations within that twenty-four month window the addresses automatically become property of ARIN and are placed in the free pool. After that period of time regular transfer rights exist. All subsequent allocations / transfers require regular needs testing. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. My reasoning of allowing follow up transfers is within the first two years, but not allowing transfers out for twenty-four months from the last transfer is it encourages companies to go for a small initial allocation rather than buying their max possible size initially knowing that they next time they will need to go through needs testing. Any thoughts? Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, September 28, 2015 11:11 AM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks I?m not going to support anything that provides a blanket exemption from needs basis. I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). Owen On Sep 26, 2015, at 19:48 , Adam Thompson > wrote: At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. -Adam On September 26, 2015 8:47:46 PM CDT, Brian Jones > wrote: I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. -- Brian On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler > wrote: Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 28 15:08:35 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Sep 2015 12:08:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> References: <5605331E.30306@velea.eu> <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> Message-ID: <3BFBBA9E-0E23-48F2-9321-86744C4DF653@delong.com> > On Sep 28, 2015, at 11:50 , Bill Buhler wrote: > > Thanks Owen for your thoughts, it sounds to me like we are getting a lot closer to a compromise, would this be a sufficient circuit breaker: > > Small end users and ISPs are allowed initial and follow up transfers up to a /20 for ISPs or /22 for end users from the market. These transfers can be conducted in no more than three operations over a 24 month period. None of the transferred addresses can be transferred to another entity for twenty-four months following the date of the last transfer. If the company ceases operations within that twenty-four month window the addresses automatically become property of ARIN and are placed in the free pool. After that period of time regular transfer rights exist. Property is a loaded term in this context. I would be OK with the proposal, but we would need to change ?automatically become property of...? to ?are automatically returned to the ARIN free pool?. Also, you?re still allowing ?follow up? transfers without needs testing. So there?s ambiguity as to whether you mean follow-ups up to a total holding of (/20,/22) or if you mean there?s a new (/20,/22) followup cycle each 24 months. The former would be acceptable to me. The latter would not. > All subsequent allocations / transfers require regular needs testing. > > Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. > > My reasoning of allowing follow up transfers is within the first two years, but not allowing transfers out for twenty-four months from the last transfer is it encourages companies to go for a small initial allocation rather than buying their max possible size initially knowing that they next time they will need to go through needs testing. I don?t see any reason to worry about this in the transfer market. We allow for a 24 month need, so there?s no overall advantage IMHO to facilitating a smaller initial transfer and allowing subsequent transfers without need, but if people feel this is useful, I can live with it. Personally, I think it just encourages fragmentation of the routing table without providing a tangible benefit. Owen > > Any thoughts? > > Bill Buhler > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Monday, September 28, 2015 11:11 AM > To: Adam Thompson > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > I?m not going to support anything that provides a blanket exemption from needs basis. > > I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. > > I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). > > Owen > > On Sep 26, 2015, at 19:48 , Adam Thompson > wrote: > > At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). > Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. > -Adam > > > On September 26, 2015 8:47:46 PM CDT, Brian Jones > wrote: > I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. > > -- > Brian > > On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler > wrote: > Having watched this for the last couple of years let me make a couple of observations / one proposal: > > There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. > > On the other side there seem to be a couple of thoughts: > > 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. > 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. > > I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. > > So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: > > Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. > > All transfers larger than a /22 need to have needs based justification done based on the current model. > > > If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. > > Best regards, > > Bill Buhler > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Steven Ryerse > Sent: Friday, September 25, 2015 11:48 AM > To: Owen DeLong > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > Owens comment from below: > ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? > > Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! > > It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong > Sent: Friday, September 25, 2015 1:24 PM > To: elvis at velea.eu > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. > the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? > > Sure, except it isn?t actually an outcome of the proposal on many levels: > > 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. > 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. > 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. > > > > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. > So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? > Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). > > > Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. > > OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. > > > I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. > > I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. > > > Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. > The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. > > Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? > > Owen > > > > Richard > regards, > Elvis > > > ________________________________________ > From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net > > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Mon Sep 28 15:59:30 2015 From: bill at tknow.com (Bill Buhler) Date: Mon, 28 Sep 2015 19:59:30 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <3BFBBA9E-0E23-48F2-9321-86744C4DF653@delong.com> References: <5605331E.30306@velea.eu> <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> <3BFBBA9E-0E23-48F2-9321-86744C4DF653@delong.com> Message-ID: OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, September 28, 2015 1:09 PM To: Bill Buhler Cc: Adam Thompson; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 28, 2015, at 11:50 , Bill Buhler > wrote: Thanks Owen for your thoughts, it sounds to me like we are getting a lot closer to a compromise, would this be a sufficient circuit breaker: Small end users and ISPs are allowed initial and follow up transfers up to a /20 for ISPs or /22 for end users from the market. These transfers can be conducted in no more than three operations over a 24 month period. None of the transferred addresses can be transferred to another entity for twenty-four months following the date of the last transfer. If the company ceases operations within that twenty-four month window the addresses automatically become property of ARIN and are placed in the free pool. After that period of time regular transfer rights exist. Property is a loaded term in this context. I would be OK with the proposal, but we would need to change ?automatically become property of...? to ?are automatically returned to the ARIN free pool?. Also, you?re still allowing ?follow up? transfers without needs testing. So there?s ambiguity as to whether you mean follow-ups up to a total holding of (/20,/22) or if you mean there?s a new (/20,/22) followup cycle each 24 months. The former would be acceptable to me. The latter would not. All subsequent allocations / transfers require regular needs testing. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. My reasoning of allowing follow up transfers is within the first two years, but not allowing transfers out for twenty-four months from the last transfer is it encourages companies to go for a small initial allocation rather than buying their max possible size initially knowing that they next time they will need to go through needs testing. I don?t see any reason to worry about this in the transfer market. We allow for a 24 month need, so there?s no overall advantage IMHO to facilitating a smaller initial transfer and allowing subsequent transfers without need, but if people feel this is useful, I can live with it. Personally, I think it just encourages fragmentation of the routing table without providing a tangible benefit. Owen Any thoughts? Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, September 28, 2015 11:11 AM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks I?m not going to support anything that provides a blanket exemption from needs basis. I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). Owen On Sep 26, 2015, at 19:48 , Adam Thompson > wrote: At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. -Adam On September 26, 2015 8:47:46 PM CDT, Brian Jones > wrote: I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. -- Brian On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler > wrote: Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 28 17:20:20 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Sep 2015 14:20:20 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <5605331E.30306@velea.eu> <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> <3BFBBA9E-0E23-48F2-9321-86744C4DF653@delong.com> Message-ID: <3529F4D6-1C6E-41D9-9739-1CE767BFE5A5@delong.com> I could live with this. Do you need help putting it into a proposal template? Owen > On Sep 28, 2015, at 12:59 , Bill Buhler wrote: > > OK, how about this: > > Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: > > a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. > b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. > c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. > d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. > e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. > f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. > > > ------------------- > > I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. > > Best regards, > > Bill Buhler > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, September 28, 2015 1:09 PM > To: Bill Buhler > Cc: Adam Thompson; arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > On Sep 28, 2015, at 11:50 , Bill Buhler > wrote: > > Thanks Owen for your thoughts, it sounds to me like we are getting a lot closer to a compromise, would this be a sufficient circuit breaker: > > Small end users and ISPs are allowed initial and follow up transfers up to a /20 for ISPs or /22 for end users from the market. These transfers can be conducted in no more than three operations over a 24 month period. None of the transferred addresses can be transferred to another entity for twenty-four months following the date of the last transfer. If the company ceases operations within that twenty-four month window the addresses automatically become property of ARIN and are placed in the free pool. After that period of time regular transfer rights exist. > > Property is a loaded term in this context. > > I would be OK with the proposal, but we would need to change ?automatically become property of...? to ?are automatically returned to the ARIN free pool?. > > Also, you?re still allowing ?follow up? transfers without needs testing. So there?s ambiguity as to whether you mean follow-ups up to a total holding of (/20,/22) or if you mean there?s a new (/20,/22) followup cycle each 24 months. > > The former would be acceptable to me. The latter would not. > > > > All subsequent allocations / transfers require regular needs testing. > > Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. > > > My reasoning of allowing follow up transfers is within the first two years, but not allowing transfers out for twenty-four months from the last transfer is it encourages companies to go for a small initial allocation rather than buying their max possible size initially knowing that they next time they will need to go through needs testing. > > I don?t see any reason to worry about this in the transfer market. We allow for a 24 month need, so there?s no overall advantage IMHO to facilitating a smaller initial transfer and allowing subsequent transfers without need, but if people feel this is useful, I can live with it. Personally, I think it just encourages fragmentation of the routing table without providing a tangible benefit. > > Owen > > > > Any thoughts? > > Bill Buhler > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong > Sent: Monday, September 28, 2015 11:11 AM > To: Adam Thompson > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > I?m not going to support anything that provides a blanket exemption from needs basis. > > I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. > > I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). > > Owen > > On Sep 26, 2015, at 19:48 , Adam Thompson > wrote: > > At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). > Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. > -Adam > > > > On September 26, 2015 8:47:46 PM CDT, Brian Jones > wrote: > I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. > > -- > Brian > > On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler > wrote: > Having watched this for the last couple of years let me make a couple of observations / one proposal: > > There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. > > On the other side there seem to be a couple of thoughts: > > 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. > 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. > > I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. > > So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: > > Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. > > All transfers larger than a /22 need to have needs based justification done based on the current model. > > > If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. > > Best regards, > > Bill Buhler > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Steven Ryerse > Sent: Friday, September 25, 2015 11:48 AM > To: Owen DeLong > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > Owens comment from below: > ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? > > Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! > > It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong > Sent: Friday, September 25, 2015 1:24 PM > To: elvis at velea.eu > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > > On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: > > Hi Richard, > > On 25/09/15 06:46, Richard J. Letts wrote: > > b) > There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. > the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? > > Sure, except it isn?t actually an outcome of the proposal on many levels: > > 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. > 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. > 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. > > > > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. > So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? > Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). > > > Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. > > OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. > > > I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. > > I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. > > > Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. > The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. > > Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? > > Owen > > > > Richard > regards, > Elvis > > > ________________________________________ > From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > > Sent: Thursday, September 24, 2015 6:20 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > | Date: Wed, 23 Sep 2015 16:53:59 -0400 > | From: ARIN > > | To: arin-ppml at arin.net > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > | Message-ID: <56031167.1010007 at arin.net > > | Content-Type: text/plain; charset=utf-8; format=flowed > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 > | transfers of IPv4 netblocks > | > | On 17 September 2015 the ARIN Advisory Council (AC) accepted > | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, > | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. > | > | Draft Policy ARIN-2015-9 is below and can be found at: > | https://www.arin.net/policy/proposals/2015_9.html > > Greetings, > > There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: > a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? > b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? > > -- > Dani Roisman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Mon Sep 28 21:18:27 2015 From: bill at tknow.com (Bill Buhler) Date: Tue, 29 Sep 2015 01:18:27 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <3529F4D6-1C6E-41D9-9739-1CE767BFE5A5@delong.com> References: <5605331E.30306@velea.eu> <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> <3BFBBA9E-0E23-48F2-9321-86744C4DF653@delong.com> <3529F4D6-1C6E-41D9-9739-1CE767BFE5A5@delong.com> Message-ID: <969e4a88efaa48499f234e47530a9602@TK-Ex13.ad.tknow.com> I would love some help. From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, September 28, 2015 3:20 PM To: Bill Buhler Cc: Adam Thompson; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks I could live with this. Do you need help putting it into a proposal template? Owen On Sep 28, 2015, at 12:59 , Bill Buhler > wrote: OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, September 28, 2015 1:09 PM To: Bill Buhler Cc: Adam Thompson; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 28, 2015, at 11:50 , Bill Buhler > wrote: Thanks Owen for your thoughts, it sounds to me like we are getting a lot closer to a compromise, would this be a sufficient circuit breaker: Small end users and ISPs are allowed initial and follow up transfers up to a /20 for ISPs or /22 for end users from the market. These transfers can be conducted in no more than three operations over a 24 month period. None of the transferred addresses can be transferred to another entity for twenty-four months following the date of the last transfer. If the company ceases operations within that twenty-four month window the addresses automatically become property of ARIN and are placed in the free pool. After that period of time regular transfer rights exist. Property is a loaded term in this context. I would be OK with the proposal, but we would need to change ?automatically become property of...? to ?are automatically returned to the ARIN free pool?. Also, you?re still allowing ?follow up? transfers without needs testing. So there?s ambiguity as to whether you mean follow-ups up to a total holding of (/20,/22) or if you mean there?s a new (/20,/22) followup cycle each 24 months. The former would be acceptable to me. The latter would not. All subsequent allocations / transfers require regular needs testing. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. My reasoning of allowing follow up transfers is within the first two years, but not allowing transfers out for twenty-four months from the last transfer is it encourages companies to go for a small initial allocation rather than buying their max possible size initially knowing that they next time they will need to go through needs testing. I don?t see any reason to worry about this in the transfer market. We allow for a 24 month need, so there?s no overall advantage IMHO to facilitating a smaller initial transfer and allowing subsequent transfers without need, but if people feel this is useful, I can live with it. Personally, I think it just encourages fragmentation of the routing table without providing a tangible benefit. Owen Any thoughts? Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, September 28, 2015 11:11 AM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks I?m not going to support anything that provides a blanket exemption from needs basis. I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). Owen On Sep 26, 2015, at 19:48 , Adam Thompson > wrote: At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. -Adam On September 26, 2015 8:47:46 PM CDT, Brian Jones > wrote: I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. -- Brian On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler > wrote: Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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 mm at VR.ORG Mon Sep 28 21:36:28 2015 From: mm at VR.ORG (Mark Mahle) Date: Tue, 29 Sep 2015 01:36:28 +0000 (GMT+00:00) Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> <3BFBBA9E-0E23-48F2-9321-86744C4DF653@delong.com> Message-ID: <1760671534.353044.1443490588764.JavaMail.zimbra@vr.org> Bill, Great compromise proposal. Can you clarify your point b) -- why limit the number of inbound transfers to reach n size in a ? Thanks, Mark From: "Bill Buhler" To: "owen" Cc: arin-ppml at arin.net Sent: Monday, September 28, 2015 12:59:30 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, September 28, 2015 1:09 PM To: Bill Buhler Cc: Adam Thompson; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 28, 2015, at 11:50 , Bill Buhler < bill at tknow.com > wrote: Thanks Owen for your thoughts, it sounds to me like we are getting a lot closer to a compromise, would this be a sufficient circuit breaker: Small end users and ISPs are allowed initial and follow up transfers up to a /20 for ISPs or /22 for end users from the market. These transfers can be conducted in no more than three operations over a 24 month period. None of the transferred addresses can be transferred to another entity for twenty-four months following the date of the last transfer. If the company ceases operations within that twenty-four month window the addresses automatically become property of ARIN and are placed in the free pool. After that period of time regular transfer rights exist. Property is a loaded term in this context. I would be OK with the proposal, but we would need to change ?automatically become property of...? to ?are automatically returned to the ARIN free pool?. Also, you?re still allowing ?follow up? transfers without needs testing. So there?s ambiguity as to whether you mean follow-ups up to a total holding of (/20,/22) or if you mean there?s a new (/20,/22) followup cycle each 24 months. The former would be acceptable to me. The latter would not. All subsequent allocations / transfers require regular needs testing. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. BQ_BEGIN My reasoning of allowing follow up transfers is within the first two years, but not allowing transfers out for twenty-four months from the last transfer is it encourages companies to go for a small initial allocation rather than buying their max possible size initially knowing that they next time they will need to go through needs testing. BQ_END I don?t see any reason to worry about this in the transfer market. We allow for a 24 month need, so there?s no overall advantage IMHO to facilitating a smaller initial transfer and allowing subsequent transfers without need, but if people feel this is useful, I can live with it. Personally, I think it just encourages fragmentation of the routing table without providing a tangible benefit. Owen Any thoughts? Bill Buhler From: arin-ppml-bounces at arin.net [ mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong Sent: Monday, September 28, 2015 11:11 AM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks I?m not going to support anything that provides a blanket exemption from needs basis. I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). Owen BQ_BEGIN On Sep 26, 2015, at 19:48 , Adam Thompson < athompso at athompso.net > wrote: At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. -Adam On September 26, 2015 8:47:46 PM CDT, Brian Jones < bjones at vt.edu > wrote: I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. -- Brian On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler < bill at tknow.com > wrote: Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto: arin-ppml-bounces at arin.net ] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office ? Eclipse Networks, Inc. Conquering Complex Networks ? From: arin-ppml-bounces at arin.net [ mailto:arin-ppml-bounces at arin.net ] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks BQ_BEGIN On Sep 25, 2015, at 04:42 , Elvis Daniel Velea < elvis at velea.eu > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: BQ_BEGIN b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. BQ_END the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? BQ_END Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. BQ_BEGIN BQ_BEGIN It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. BQ_END So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). BQ_END Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. BQ_BEGIN I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. BQ_END I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. BQ_BEGIN BQ_BEGIN Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. BQ_END The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. BQ_END Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen BQ_BEGIN BQ_BEGIN Richard BQ_END regards, Elvis BQ_BEGIN ________________________________________ From: arin-ppml-bounces at arin.net < arin-ppml-bounces at arin.net > on behalf of Dani Roisman < droisman at softlayer.com > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN < info at arin.net > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: < 56031167.1010007 at arin.net > | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. BQ_END _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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. BQ_END _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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. BQ_END _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Mon Sep 28 22:15:33 2015 From: bjones at vt.edu (Brian Jones) Date: Mon, 28 Sep 2015 22:15:33 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> References: <5605331E.30306@velea.eu> <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> Message-ID: On Sep 28, 2015 1:11 PM, "Owen DeLong" wrote: > > I?m not going to support anything that provides a blanket exemption from needs basis. > > I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. > > I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). > > Owen Thanks for these thoughts Owen. +1 on your points made here. > >> On Sep 26, 2015, at 19:48 , Adam Thompson wrote: >> >> At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). >> Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. >> -Adam >> >> >> On September 26, 2015 8:47:46 PM CDT, Brian Jones wrote: >>> >>> I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. >>> >>> -- >>> Brian >>> >>> On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler wrote: >>>> >>>> Having watched this for the last couple of years let me make a couple of observations / one proposal: >>>> >>>> >>>> >>>> There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. >>>> >>>> >>>> >>>> On the other side there seem to be a couple of thoughts: >>>> >>>> >>>> >>>> 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. >>>> >>>> 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. >>>> >>>> >>>> >>>> I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. >>>> >>>> >>>> >>>> So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: >>>> >>>> >>>> >>>> Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. >>>> >>>> >>>> >>>> All transfers larger than a /22 need to have needs based justification done based on the current model. >>>> >>>> >>>> >>>> >>>> >>>> If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> >>>> >>>> Bill Buhler >>>> >>>> >>>> >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse >>>> Sent: Friday, September 25, 2015 11:48 AM >>>> To: Owen DeLong >>>> >>>> >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> >>>> >>>> Owens comment from below: >>>> >>>> ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? >>>> >>>> >>>> >>>> Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! >>>> >>>> >>>> >>>> It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! >>>> >>>> >>>> >>>> Steven Ryerse >>>> >>>> President >>>> >>>> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >>>> >>>> 770.656.1460 - Cell >>>> >>>> 770.399.9099- Office >>>> >>>> >>>> >>>> ? Eclipse Networks, Inc. >>>> >>>> Conquering Complex Networks? >>>> >>>> >>>> >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong >>>> Sent: Friday, September 25, 2015 1:24 PM >>>> To: elvis at velea.eu >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>> >>>> >>>> >>>> >>>>> >>>>> On Sep 25, 2015, at 04:42 , Elvis Daniel Velea wrote: >>>>> >>>>> >>>>> >>>>> Hi Richard, >>>>> >>>>> On 25/09/15 06:46, Richard J. Letts wrote: >>>>>> >>>>>> b) >>>>>> There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. >>>>> >>>>> the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? >>>> >>>> >>>> >>>> Sure, except it isn?t actually an outcome of the proposal on many levels: >>>> >>>> >>>> >>>> 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. >>>> >>>> 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. >>>> >>>> 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. >>>> >>>> >>>>>> >>>>>> >>>>>> It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. >>>>> >>>>> So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? >>>>> Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). >>>> >>>> >>>> >>>> Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. >>>> >>>> >>>> >>>> OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. >>>> >>>> >>>>> >>>>> I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. >>>> >>>> >>>> >>>> I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. >>>> >>>> >>>>>> >>>>>> Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. >>>>> >>>>> The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. >>>> >>>> >>>> >>>> Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? >>>> >>>> >>>> >>>> Owen >>>> >>>> >>>>>> >>>>>> >>>>>> Richard >>>>> >>>>> regards, >>>>> Elvis >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: arin-ppml-bounces at arin.net on behalf of Dani Roisman >>>>>> Sent: Thursday, September 24, 2015 6:20 PM >>>>>> To: arin-ppml at arin.net >>>>>> Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>>>> >>>>>> | Date: Wed, 23 Sep 2015 16:53:59 -0400 >>>>>> | From: ARIN >>>>>> | To: arin-ppml at arin.net >>>>>> | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based >>>>>> | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >>>>>> | Message-ID: <56031167.1010007 at arin.net> >>>>>> | Content-Type: text/plain; charset=utf-8; format=flowed >>>>>> | >>>>>> | Draft Policy ARIN-2015-9 >>>>>> | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 >>>>>> | transfers of IPv4 netblocks >>>>>> | >>>>>> | On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>> | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, >>>>>> | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. >>>>>> | >>>>>> | Draft Policy ARIN-2015-9 is below and can be found at: >>>>>> | https://www.arin.net/policy/proposals/2015_9.html >>>>>> >>>>>> Greetings, >>>>>> >>>>>> There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: >>>>>> a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? >>>>>> b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? >>>>>> >>>>>> -- >>>>>> Dani Roisman >>>>>> _______________________________________________ >>>>>> PPML >>>>>> You are receiving this message because you are subscribed to >>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> Please contact info at arin.net if you experience any issues. >>>>>> _______________________________________________ >>>>>> PPML >>>>>> You are receiving this message because you are subscribed to >>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> Please contact info at arin.net if you experience any issues. >>>>> >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >>> ________________________________ >>> >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing 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. >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Tue Sep 29 09:33:39 2015 From: bill at tknow.com (Bill Buhler) Date: Tue, 29 Sep 2015 13:33:39 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <1760671534.353044.1443490588764.JavaMail.zimbra@vr.org> References: <9BD3A44D-516F-4FED-817F-5A1CFD0977E6@athompso.net> <334DDA03-FA0C-4F73-BE33-68304EEC1B4B@delong.com> <851f1f2a9534453f8d4bdead34bcc001@TK-Ex13.ad.tknow.com> <3BFBBA9E-0E23-48F2-9321-86744C4DF653@delong.com> <1760671534.353044.1443490588764.JavaMail.zimbra@vr.org> Message-ID: <7f3a0b03fe1a47c59a53553b59d20b3e@TK-Ex13.ad.tknow.com> I wanted to allow some growth before needs analysis became necessary (but prevent way overestimating need), but prevent the customer from getting a /24 every month as needed and greatly increasing the fragmentation of the routing table. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mark Mahle Sent: Monday, September 28, 2015 7:36 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Bill, Great compromise proposal. Can you clarify your point b) -- why limit the number of inbound transfers to reach n size in a ? Thanks, Mark ________________________________ From: "Bill Buhler" > To: "owen" > Cc: arin-ppml at arin.net Sent: Monday, September 28, 2015 12:59:30 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, September 28, 2015 1:09 PM To: Bill Buhler Cc: Adam Thompson; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 28, 2015, at 11:50 , Bill Buhler > wrote: Thanks Owen for your thoughts, it sounds to me like we are getting a lot closer to a compromise, would this be a sufficient circuit breaker: Small end users and ISPs are allowed initial and follow up transfers up to a /20 for ISPs or /22 for end users from the market. These transfers can be conducted in no more than three operations over a 24 month period. None of the transferred addresses can be transferred to another entity for twenty-four months following the date of the last transfer. If the company ceases operations within that twenty-four month window the addresses automatically become property of ARIN and are placed in the free pool. After that period of time regular transfer rights exist. Property is a loaded term in this context. I would be OK with the proposal, but we would need to change ?automatically become property of...? to ?are automatically returned to the ARIN free pool?. Also, you?re still allowing ?follow up? transfers without needs testing. So there?s ambiguity as to whether you mean follow-ups up to a total holding of (/20,/22) or if you mean there?s a new (/20,/22) followup cycle each 24 months. The former would be acceptable to me. The latter would not. All subsequent allocations / transfers require regular needs testing. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. My reasoning of allowing follow up transfers is within the first two years, but not allowing transfers out for twenty-four months from the last transfer is it encourages companies to go for a small initial allocation rather than buying their max possible size initially knowing that they next time they will need to go through needs testing. I don?t see any reason to worry about this in the transfer market. We allow for a 24 month need, so there?s no overall advantage IMHO to facilitating a smaller initial transfer and allowing subsequent transfers without need, but if people feel this is useful, I can live with it. Personally, I think it just encourages fragmentation of the routing table without providing a tangible benefit. Owen Any thoughts? Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, September 28, 2015 11:11 AM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks I?m not going to support anything that provides a blanket exemption from needs basis. I will support a change which allows an initial allocation/assignment/transfer of a minimal block of addresses (up to a /22 for an end-user or up to a /20 for an ISP seems reasonable to me) so long as it also includes anti-flip protections and some language preventing spinning up related party entities strictly for address acquisition. I believe this would address most of the concerns expressed (other than those seeking to eliminate needs basis altogether). Owen On Sep 26, 2015, at 19:48 , Adam Thompson > wrote: At this point, I support anything that looks like a compromise so we can get *any* change in policy at all... So this looks like a decent compromise to me. Yes, it'll have to be revisited in a couple of years' time; yes, the specifics probably aren't perfect. The community can change those. The policy can even be written such that ARIN staff can change them independently (although this doesn't seem to be a popular model). Insisting on perfection is just hamstringing the entire service region... both the speculators *and* legitimate users. -Adam On September 26, 2015 8:47:46 PM CDT, Brian Jones > wrote: I find Bill's proposal an interesting middle ground approach. I do not believe completely eliminating needs-based justification for addresses is the correct thing to do. -- Brian On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler > wrote: Having watched this for the last couple of years let me make a couple of observations / one proposal: There seems to be a lot of fear on both sides of this debate, on the needs test side there seems to be a complete fear of monopolization of the IP address space by those with deep pockets. On the other side there seem to be a couple of thoughts: 1. It?s a market, markets work best when freed from constraints that increase the complexity of non-harmful transactions, and that allowing companies to more freely exchange IP resources is not harmful. 2. Not liking to justify future and current operations to a third party / fear of rejection by this process. I may not have encapsulated both arguments well, and these have been hashed over again and again for the last few years. So what is different today? ARIN has allocated every last resource from the free pool, and has a long waiting list. So what if we strike a compromise? What if some restrictions were put on allocation size and frequency without a needs test and left only the truly large or frequent transactions to do it. Something like this: Every legal entity can obtain up to a /22 from the transfer market every year, in up to two transactions. They may not transfer these resources out of their network within twelve months. Each legal entity has to occupy a unique address (suite level) from any other entity in the ARIN database. All transfers larger than a /22 need to have needs based justification done based on the current model. If you wanted to speculate, you would need to spin-up dozens of entities all with unique mailstops, and you would have to camp on the addresses for a year. Meanwhile the small end users and ISPs could obtain up to a /22 of a resource that with a lot of careful use of NAT would support a fairly large public network. Best regards, Bill Buhler From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, September 25, 2015 11:48 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Owens comment from below: ?2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them.? Owen?s comment is absolutely false!!!!! It allows large organizing who request resources to get what they need or something smaller. It allows medium size organizations who request resources to get what they need or something smaller. It allows small organizations who request resources to get what they need or nothing, and there is no other source to get resources if ARIN rejects a request, but the open market which Owen and others seem to wish did not exist! It is time to fix this inequity and removing needs tests would be a big help to small organizations who really need resources! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 25, 2015 1:24 PM To: elvis at velea.eu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 25, 2015, at 04:42 , Elvis Daniel Velea > wrote: Hi Richard, On 25/09/15 06:46, Richard J. Letts wrote: b) There is no definitive outcome from the policy change, which makes me feel that it's not worth changing -- the problem statement argument is weak at best. the outcome is that everyone that will need IP addresses will be able to get them. Isn't that quite definitive and clear? Sure, except it isn?t actually an outcome of the proposal on many levels: 1. The proposal does nothing to guarantee a supply of addresses or even increase the supply. 2. To the extent that there is supply, anyone who needs addresses can get them already. Needs-based evaluation does not prevent those with need from getting addresses? It prevents those without need from getting them. 3. The definitive outcome from the policy change, if there is such, is that those without need will now be more easily able to acquire addresses, potentially preventing those with need from acquiring them. It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. So, you think that in today's market the non-profit/educational organizations will have the chance at getting some of the IP space from the market? And if the needs-based barrier is removed, they will no longer have that chance? Everyone knows that the IP address is now an asset and is worth a buck. Who do you think will say: I'll give it for free to this educational organization (because they have proven the need to ARIN) instead of giving it for money to this commercial entity (that may or may not have a demonstrated need need for it). Contrary to your statement, there have been addresses returned to ARIN and there have been organizations who chose to transfer addresses to those they found worthy rather than maximize the monetization of those addresses. OTOH, having a policy like this in place certainly makes it easier to manipulate the market to maximize the price. I think we need to wake up. Keeping needs-based criteria in the policy will only cause SOME transfers to be driven underground and block some others. I think claiming that those of us who believe needs-based criteria is still useful are asleep is unwarranted. Changing policy just to (potentially) improve the accuracy of a database seems not worth the (potential) risk. The change of the accuracy of the registry is already proven in the RIPE region. I would say it's not just potential, it is real and visible. Please provide the metrics on which you base this assertion. How was RIPE-NCC accuracy measured prior to the policy change and to what extent was it improved as a result of this policy change. What mechanism was used to determine that the measured increase in accuracy was the result of the particular policy abandoning needs-based evaluation? Owen Richard regards, Elvis ________________________________________ From: arin-ppml-bounces at arin.net > on behalf of Dani Roisman > Sent: Thursday, September 24, 2015 6:20 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Date: Wed, 23 Sep 2015 16:53:59 -0400 | From: ARIN > | To: arin-ppml at arin.net | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks | Message-ID: <56031167.1010007 at arin.net> | Content-Type: text/plain; charset=utf-8; format=flowed | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 | transfers of IPv4 netblocks | | On 17 September 2015 the ARIN Advisory Council (AC) accepted | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3, | and 8.4 transfers of IPv4 netblocks" as a Draft Policy. | | Draft Policy ARIN-2015-9 is below and can be found at: | https://www.arin.net/policy/proposals/2015_9.html Greetings, There has been some stimulating dialog about the merits of 2015-9. I'd like to ask that in addition to any overall support or lack thereof, you also review the policy language and comment specifically on the changes proposed: a) For those of you generally in support of this effort, are there any refinements to the changes made which you think will improve this should these policy changes be implemented? b) For those of you generally opposed to this effort, are there any adjustments to the policy changes which, if implemented, would gain your support? -- Dani Roisman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From droisman at softlayer.com Wed Sep 30 06:52:01 2015 From: droisman at softlayer.com (Dani Roisman) Date: Wed, 30 Sep 2015 10:52:01 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Message-ID: Hi Bill, I'm interested to learn how you came up with the below proposed netblock sizes "/20 if a ISP or /22 for an end user" ? Is there data behind that? If not, does it make sense to ask ARIN to supply data regarding sizes of transfers which have occurred in the past 12 - 18 months? -- Dani Roisman ________________________________ From: "Bill Buhler" >> To: "owen" >> Cc: arin-ppml at arin.net> Sent: Monday, September 28, 2015 12:59:30 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Wed Sep 30 10:35:13 2015 From: bill at tknow.com (Bill Buhler) Date: Wed, 30 Sep 2015 14:35:13 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: Based on the ARIN fee table of ISP classification: /20 is the max allocation size of a X-Small ISP /22 is the max allocation size of a XX-Small End User. So there is a slight bias towards small ISPs, but they are in less of a position to leverage NAT. Thanks, Bill Buhler From: Dani Roisman [mailto:droisman at softlayer.com] Sent: Wednesday, September 30, 2015 4:52 AM To: arin-ppml at arin.net; Bill Buhler Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Hi Bill, I'm interested to learn how you came up with the below proposed netblock sizes "/20 if a ISP or /22 for an end user" ? Is there data behind that? If not, does it make sense to ask ARIN to supply data regarding sizes of transfers which have occurred in the past 12 - 18 months? -- Dani Roisman ________________________________ From: "Bill Buhler" >> To: "owen" >> Cc: arin-ppml at arin.net> Sent: Monday, September 28, 2015 12:59:30 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler -------------- next part -------------- An HTML attachment was scrubbed... URL: From droisman at softlayer.com Wed Sep 30 12:40:00 2015 From: droisman at softlayer.com (Dani Roisman) Date: Wed, 30 Sep 2015 16:40:00 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: That's just billing buckets then, not really based on actual transfer activity. Maybe it will help to look at more relevant data? ARIN staff watching - could you point me to any published statistics for transfers over the past 18 months, or if not could you generate them and share? I'm thinking this is a good start: 1) Number of transfers requests for each block size for 8.3 and 8.4 transfers which completed. e.g. "/20 = qty 15, /19 = qty 5, /18 = qty 10" 2) Number of transfers requests for each block size for 8.3 and 8.4 transfers which were closed without completion, specifically where need was not met I'm only asking for 8.3 and 8.4 because 8.2 doesn't have the same type of needs demonstration burden (only as usage demonstration). Thanks. ---- Dani Roisman From: Bill Buhler [mailto:bill at tknow.com] Sent: Wednesday, September 30, 2015 09:35 To: Dani Roisman ; arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Based on the ARIN fee table of ISP classification: /20 is the max allocation size of a X-Small ISP /22 is the max allocation size of a XX-Small End User. So there is a slight bias towards small ISPs, but they are in less of a position to leverage NAT. Thanks, Bill Buhler From: Dani Roisman [mailto:droisman at softlayer.com] Sent: Wednesday, September 30, 2015 4:52 AM To: arin-ppml at arin.net; Bill Buhler Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Hi Bill, I'm interested to learn how you came up with the below proposed netblock sizes "/20 if a ISP or /22 for an end user" ? Is there data behind that? If not, does it make sense to ask ARIN to supply data regarding sizes of transfers which have occurred in the past 12 - 18 months? -- Dani Roisman ________________________________ From: "Bill Buhler" >> To: "owen" >> Cc: arin-ppml at arin.net> Sent: Monday, September 28, 2015 12:59:30 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Sep 30 13:15:48 2015 From: jcurran at arin.net (John Curran) Date: Wed, 30 Sep 2015 17:15:48 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <0B23AE12-F4D0-4961-BB34-8DF5A9B5EC7F@corp.arin.net> On Sep 30, 2015, at 12:40 PM, Dani Roisman > wrote: That?s just billing buckets then, not really based on actual transfer activity. Maybe it will help to look at more relevant data? ARIN staff watching - could you point me to any published statistics for transfers over the past 18 months, or if not could you generate them and share? I?m thinking this is a good start: 1) Number of transfers requests for each block size for 8.3 and 8.4 transfers which completed. e.g. ?/20 = qty 15, /19 = qty 5, /18 = qty 10? The list of transfers completed is available online here - 2) Number of transfers requests for each block size for 8.3 and 8.4 transfers which were closed without completion, specifically where need was not met This may not be possible, but we will see what statistics are available regarding transfers not completed (the reason that ?specifically where need not met? may not be meaningful is because such requests often close due to prolonged lack of response while awaiting documentation or because they?re closed by the original requester but not otherwise distinguished, etc.) /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Sep 30 15:28:41 2015 From: jcurran at arin.net (John Curran) Date: Wed, 30 Sep 2015 19:28:41 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <0B23AE12-F4D0-4961-BB34-8DF5A9B5EC7F@corp.arin.net> References: <0B23AE12-F4D0-4961-BB34-8DF5A9B5EC7F@corp.arin.net> Message-ID: On Sep 30, 2015, at 1:15 PM, John Curran > wrote: On Sep 30, 2015, at 12:40 PM, Dani Roisman > wrote: That?s just billing buckets then, not really based on actual transfer activity. Maybe it will help to look at more relevant data? ARIN staff watching - could you point me to any published statistics for transfers over the past 18 months, or if not could you generate them and share? I?m thinking this is a good start: 1) Number of transfers requests for each block size for 8.3 and 8.4 transfers which completed. e.g. ?/20 = qty 15, /19 = qty 5, /18 = qty 10? The list of transfers completed is available online here - 2) Number of transfers requests for each block size for 8.3 and 8.4 transfers which were closed without completion, specifically where need was not met This may not be possible, but we will see what statistics are available regarding transfers not completed (the reason that ?specifically where need not met? may not be meaningful is because such requests often close due to prolonged lack of response while awaiting documentation or because they?re closed by the original requester but not otherwise distinguished, etc.) Unfortunately, we do not have any readily-available way to correlate the not-completed tickets with intended block size. We do have overall transfer ticket closure statistics available. 8.3 / 8.2 Ticket statistics to date - 153 8.3 tickets closed 106 completed (69%) 37 withdrawn (24%) 4 duplicate (3%) 3 abandoned (2%) 3 closed for another reason (2%) 82 8.2 tickets closed 68 completed (83%) 12 withdrawn (15%) 1 duplicate (1%) 1 other (1%) If one presumes that demonstration of need is a more significant concern for 8.3 transfers (generalization, but plausible) _and_ that there was no other significant factor (lots of hand-waving at this point), then there is a 9% withdrawal rate (and potentially 2% abandoned rate) that one might bravely attribute to the consequences of needs-assessment. /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjletts at uw.edu Wed Sep 30 15:42:51 2015 From: rjletts at uw.edu (Richard J. Letts) Date: Wed, 30 Sep 2015 19:42:51 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <0B23AE12-F4D0-4961-BB34-8DF5A9B5EC7F@corp.arin.net> Message-ID: Where did the 9% come from? Should that not be 24%? Either way, if we were talking about houses then many of us realize that if the number of bidders on property who had the cash (but not the need) were 10 or 25% larger, then you might expect the value of the property to be higher. The same is true with any inelastic good. I have no idea what the price elasticity of IP address space is, but I?m going to suggest that it?s very inelastic given the lack of alternatives (IPv6 is an alternative, but it has other costs associated with it) I have not seen an argument that this policy will not increase the price of IPv4 addresses for people who have needs, and I can?t see that is a good thing. Richard Letts From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: 30 September 2015 12:29 PM To: Dani Roisman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks On Sep 30, 2015, at 1:15 PM, John Curran > wrote: Unfortunately, we do not have any readily-available way to correlate the not-completed tickets with intended block size. We do have overall transfer ticket closure statistics available. 8.3 / 8.2 Ticket statistics to date - 153 8.3 tickets closed 106 completed (69%) 37 withdrawn (24%) 4 duplicate (3%) 3 abandoned (2%) 3 closed for another reason (2%) 82 8.2 tickets closed 68 completed (83%) 12 withdrawn (15%) 1 duplicate (1%) 1 other (1%) If one presumes that demonstration of need is a more significant concern for 8.3 transfers (generalization, but plausible) _and_ that there was no other significant factor (lots of hand-waving at this point), then there is a 9% withdrawal rate (and potentially 2% abandoned rate) that one might bravely attribute to the consequences of needs-assessment. /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Wed Sep 30 16:41:25 2015 From: bill at tknow.com (Bill Buhler) Date: Wed, 30 Sep 2015 20:41:25 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <218fefc9eea94dadb7b3a0bbfb25c643@TK-Ex13.ad.tknow.com> Dani, Do you have a particular reason to want to dive into the stats? I looked at them but see no way to easily separate the requests between those that would qualify for this (those that have a no or a very small IP allocation), and those of larger entities. I did run out the transfers and found the following: Size Transfers % Overall % <= /10 1 0.72% 100% /11 3 2.17% 99.28% /12 5 3.62% 97.10% /13 2 1.45% 93.48% /14 7 5.07% 92.03% /15 7 5.07% 86.96% /16 15 10.87% 81.88% /17 6 4.35% 71.01% /18 8 5.80% 66.67% /19 11 7.97% 60.87% /20 16 11.59% 52.90% /21 9 6.52% 41.30% /22 14 10.14% 34.78% /23 12 8.70% 24.64% /24 21 15.22% 15.94% /25 1 0.72% 0.72% Average block size: 19.20 Median block size: 20 Standard Deviation: 3.792 So we can see that /24 is the most popular allocation size, and ~ 50% of all transfer activity is for a /20 or smaller block. What I can't see without a lot of WHOIS work, is what the size of the entities are that transferred the smaller blocks. I suspect even if they had been subject to this policy change a large majority would still fall under the needs test provisions. Best regards, Bill Buhler From: Dani Roisman [mailto:droisman at softlayer.com] Sent: Wednesday, September 30, 2015 10:40 AM To: Bill Buhler; arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks That's just billing buckets then, not really based on actual transfer activity. Maybe it will help to look at more relevant data? ARIN staff watching - could you point me to any published statistics for transfers over the past 18 months, or if not could you generate them and share? I'm thinking this is a good start: 1) Number of transfers requests for each block size for 8.3 and 8.4 transfers which completed. e.g. "/20 = qty 15, /19 = qty 5, /18 = qty 10" 2) Number of transfers requests for each block size for 8.3 and 8.4 transfers which were closed without completion, specifically where need was not met I'm only asking for 8.3 and 8.4 because 8.2 doesn't have the same type of needs demonstration burden (only as usage demonstration). Thanks. ---- Dani Roisman From: Bill Buhler [mailto:bill at tknow.com] Sent: Wednesday, September 30, 2015 09:35 To: Dani Roisman >; arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Based on the ARIN fee table of ISP classification: /20 is the max allocation size of a X-Small ISP /22 is the max allocation size of a XX-Small End User. So there is a slight bias towards small ISPs, but they are in less of a position to leverage NAT. Thanks, Bill Buhler From: Dani Roisman [mailto:droisman at softlayer.com] Sent: Wednesday, September 30, 2015 4:52 AM To: arin-ppml at arin.net; Bill Buhler Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Hi Bill, I'm interested to learn how you came up with the below proposed netblock sizes "/20 if a ISP or /22 for an end user" ? Is there data behind that? If not, does it make sense to ask ARIN to supply data regarding sizes of transfers which have occurred in the past 12 - 18 months? -- Dani Roisman ________________________________ From: "Bill Buhler" >> To: "owen" >> Cc: arin-ppml at arin.net> Sent: Monday, September 28, 2015 12:59:30 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjletts at uw.edu Wed Sep 30 18:15:35 2015 From: rjletts at uw.edu (Richard J. Letts) Date: Wed, 30 Sep 2015 22:15:35 +0000 Subject: [arin-ppml] 11 Proposals Under Consideration In-Reply-To: <5605B8FF.9000602@umn.edu> References: <5605B8FF.9000602@umn.edu> Message-ID: Dave Farmer asked for opinions on the other proposals. -9 has been flogged close to death, here are my opinions on five of the others. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of David Farmer > Sent: 25 September 2015 2:14 PM > To: ARIN PPML > Subject: [arin-ppml] 11 Proposals Under Consideration > > There are currently 11 proposals under various stages of consideration and > development in the ARIN Policy Development Process; > > > Recommended Draft Policy ARIN-2015-1: Modification to Criteria for > IPv6 Initial End-User Assignments Looks good, expands IPv6 > > Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in > end-user IPv4 policy OK, really reasonable. ARIN staff comments on this one should be implemented as well. > > Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better > reflect how ARIN handles reorganizations OK Taking these two together: > > Draft Policy ARIN-2015-5: Out of region use > > Draft Policy ARIN-2015-6: Transfers and Multi-national Networks I'm not a fan of either of these, they only address a small number of organizations, and potentially could be solved by obtaining address space in the right RIR and renumbering the out of ARIN RIR locations, and seem to have a higher burden on ARIN staff to implement. Can policies suggest that additional fees be levied against organizations specifying out of region use, Transfers, or Multi-national Networks? Part of me feels like we should stop wasting resources trying to update IPv4 policies unless they are obviously broken for almost every organization and make sure the barriers to IPv6 are low. Richard Letts From owen at delong.com Wed Sep 30 22:42:21 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 30 Sep 2015 19:42:21 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <092EF5BD-5020-499C-8590-4857E26EF9B3@delong.com> Dani, In fairness to Bill, I think he may also have chosen them because I suggested that those would be boundaries I would consider livable. I believe they represent a good size to guarantee that small organizations are not shut out of the transfer market based on size, but still ensure that need assessment is preserved in order to prevent acquisition of addresses without intended use thereof. While a /20 is a fair quantity of addresses (4096), it?s a pretty small number of customers for an ISP in most cases and I think anything smaller would be somewhat punitive. It does also line up well with transfer history and other ARIN data about small-ish organizations and address issuance over the last several years. Owen > On Sep 30, 2015, at 03:52 , Dani Roisman wrote: > > Hi Bill, > > I?m interested to learn how you came up with the below proposed netblock sizes ?/20 if a ISP or /22 for an end user? ? Is there data behind that? If not, does it make sense to ask ARIN to supply data regarding sizes of transfers which have occurred in the past 12 - 18 months? > > -- > Dani Roisman > > ________________________________ > From: "Bill Buhler" >> > To: "owen" >> > Cc: arin-ppml at arin.net> > Sent: Monday, September 28, 2015 12:59:30 PM > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > OK, how about this: > > Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: > > > a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. > > b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. > > c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. > > d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. > > e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. > > f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. > > ------------------- > > I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. > > Best regards, > > Bill Buhler > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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: