On 2/24/2015 9:17 AM, ARIN wrote: > ARIN-2014-14 has been revised. This draft policy is open for > discussion on this mailing list. > > ARIN-2014-14 is below and can be found at: > https://www.arin.net/policy/proposals/2014_14.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2014-14 > Needs Attestation for some IPv4 Transfers > > Date: 24 Feb 2015 > > Problem Statement: > > The process of 'needs testing' or 'needs basis' allocation has evolved > over the history of the Internet registry system. The earliest number > resource policy required that an operator intend to use the number > resources on an operational Internet Protocol network before the > resource would be registered to an organization. Organizations were > assigned either a Class A, B, or C block roughly depending on the > organization's size. With the implementation of CIDR, additional > 'needs testing' was done to right size allocations to fit > organizations. These testing requirements continued to evolve under > various organizations prior to the RIRs inception and then later > formally under the RIR's policy development process. > > In the 2000s, ARIN began a systematic "trust but verify" process for > IPv4 requests. This was necessary due to both IPv4 address > registration hijackings in ARIN Whois and the accelerated amount of > systematic fraud being perpetrated on ARIN. > > As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity > of some of the needs testing requirements and implemented policies > which reduced the requirements on organizations to show need or > utilization for some transfer transactions with the RIR. > > The cost of performing a needs assessment and auditing of this > information vs. the public benefit of restricting allocations to > specifically qualified organizations has been noted by some > organizations to be out of alignment. The ability to predict future > use toward a 24-month utilization rate can also be challenging for > some organizations and relies on projections and estimates rather than > verifiable facts. Thus, the current needs testing requirements may be > more than is necessary and desirable for small transfers. This policy > seeks to reduce the complexity of transfers by removing the > utilization needs testing requirement and replacing it with a needs > attestation by a corporate officer. > > Additionally, other requirements are placed around the 'needs > attestation only' requirement to reduce the Number Resource > Community's concern that this type of policy could be abused for > speculation or hording. Furthermore, the policy includes a sunset > clause to limit the total number of transfers under this policy > proposal. This sunset is intended to force the community to reexamine > the success or failure of the practices contained in this policy proposal. > > Policy statement: > > Section 8.3 > > Replace the 'Conditions on recipient of the transfer' with the > following conditions. > > Conditions on recipient of the transfer: > > The organization must sign an RSA. > > The resources transferred will be subject to current ARIN policies. > > In addition, the recipient must meet one of the following requirements > sets: > > 1. The organization must demonstrate the need for up to a 24-month > supply of IP address resources under current ARIN policies. > > OR > > 1.The organization, its parent(s), or subsidiary organizations, must > not have received IPv4 address resources, via transfer, within the > past 12 months. > > 2.An officer of the organization must attest that the IPv4 address > block is needed for and will be used on an operational network. > > 3.The maximum transfer size is /20. > > 4.Fewer than 5,000 needs attestation transfers have occurred. > > > Section 8.4 > > Replace the 'Conditions on recipient of the transfer' with the > following conditions. > > Conditions on recipient of the transfer: > > The conditions on a recipient outside of the ARIN region will be > defined by the policies of the receiving RIR. > > Recipients within the ARIN region will be subject to current ARIN > policies and sign an RSA for the resources being received. > > The minimum transfer size is a /24. > > In addition, the recipient must meet one of the following requirements > sets: > > 1. The organization must demonstrate the need for up to a 24-month > supply of IP address resources under current ARIN policies. > > OR > > 1.The organization, its parent(s), or subsidiary organizations, must > not have received IPv4 address resources, via transfer, within the > past 12 months. > > 2.An officer of the organization must attest that the IPv4 address > block is needed for and will be used on an operational network. > > 3.The maximum transfer size is /20. > > 4.Fewer than 5,000 needs attestation transfers have occurred. > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
Hi Andrew, I think it would be clearer if the line: 4.Fewer than 5,000 needs attestation transfers have occurred. Was changed to: 4. Fewer than 5,000 transfers under this requirement set have completed. But I would support it with the current language. The maximum number of addresses which could be transferred in aggregate under this policy is 1.25 /8 equivalents. And at the current rate of transfers this would take years. Does anybody still fear damaging market manipulation could occur under this policy? Regards, Mike Burns IPTrading.com _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
