I do not oppose the policy as written. I’m not sure I support it, but if we want to conduct such an experiment, then I believe this policy provides adequate protections and limitations on the scope of the experiment.
Owen > On Feb 24, 2015, at 09:17 , ARIN <[email protected]> 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. _______________________________________________ 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.
