Mike, Your proposed language is clearer in the context of policy development, but would lack clarity when placed in the NRPM as “this requirement” becomes somewhat ambiguous.
Owen > On Mar 12, 2015, at 08:08 , Mike Burns <[email protected]> wrote: > > 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 <http://iptrading.com/> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected] > <mailto:[email protected]>). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > <http://lists.arin.net/mailman/listinfo/arin-ppml> > Please contact [email protected] <mailto:[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.
