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

[Owen DeLong]

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.