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

[Andrew Dul]

This policy draft has been significantly revised by the AC, including a
new problem statement and substantially different draft policy
language.  Conversation on PPML so far has been quite limited on this
new draft.  The AC would like to hear from members of the community on
this new language.  Specifically if you could address the following
questions it would be appreciated.

Do you agree with the new problem statement?

Do you support the new policy language?  If not, are there areas of the
text which could be modified so that you could support the draft?

If you don't support this revised language, do you believe the AC should
abandon this draft policy?

Thanks for your feedback,
Andrew

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 (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.