[arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised

[Adam Thompson]

Based on "the perfect is the enemy of the good", I figure it's worth going ahead with this.

If it turns out to be a disaster, the policy can be revised in... what's the minimum, 6 months?  And there are ways to mitigate its impact during that time if necessary.

Much as mentioned in the policy statement, we're working with estimates and guesses, not verifiable facts.  This will at least generate some verifiable facts.

I'm equally certain it will need revision/tweaking at some point fairly soon.

-Adam

On February 24, 2015 2:04:42 PM CST, Owen DeLong <owen at delong.com> wrote:
>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 <info at arin.net> 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 (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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150224/50b83182/attachment.htm>