[arin-ppml] Draft Policy ARIN-2016-3 Alternative simplified criteria for justifying small IPv4 transfers

[Jason Schiller]

I think the first order of business here is to discuss the right value for
the doubling cap.

As the policy currently reads it suggest a doubling cap of a /12 or a /16.

Organizations who are currently at 80% utilization and holding less than
or equal to the cap can simply double with one or more transfers over a
two year window.  After which they need to re-certify their utilization.

Organizations who are currently at 80% utilization and holding more than
the cap, can simply transfer in up to the cap with one or more transfers
over a two year window.  After which they need to re-certify their
utilization.

Some questions:

1. What is the "right" value for the cap?
(/12, /16, something else?)

2. Would you support this proposal if the cap was the "right" value?

3. Would you support this proposal if the cap was the "wrong" value?
(if the right value is /12, would you support /16?
  if the right value is /16, would you support /12?
  if the right value is something else would you support /12 and/or /16?)


Note organizations that need more than double, or more than the cap can:

- get the amount permitted, put it into service, re-certify utilization and
repeat.

- qualify under the current policy

___Jason





On Tue, May 24, 2016 at 5:55 PM, ARIN <info at arin.net> wrote:

> Draft Policy ARIN-2016-3 Alternative simplified criteria for justifying
> small IPv4 transfers
>
> On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-228
> Alternative simplified criteria for justifying small IPv4 transfers" as a
> Draft Policy.
>
> Draft Policy ARIN-2016-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2016_3.html
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet Number Resource Policy as stated
> in the Policy Development Process (PDP). Specifically, these principles are:
>
>   * Enabling Fair and Impartial Number Resource Administration
>   * Technically Sound
>   * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2016-3 Change timeframes for IPv4 requests to 24 months
>
> Date: 24 May 2016
>
> Problem Statement:
>
> ARIN transfer policy currently inherits all its demonstrated need
> requirements for IPv4 transfers from NRPM sections 4. Because that section
> was written primarily to deal with free pool allocations, it is much more
> complicated than is really necessary for transfers.
>
> This proposal allows organizations using 80% of their current space to
> double their current holdings via 8.3 or 8.4 specified transfers, up to a
> certain size, such as /12 or /16. Existing section 4 need demonstration
> rules would continue to apply to organizations who request more than a [
> /12 | /16] of space.
>
> Policy statement:
>
> In section 8.3, replace:
>
> The recipient must demonstrate the need for up to a 24-month supply of IP
> address resources under current ARIN policies and sign an RSA.
> with:
>
> The recipient must sign an RSA and either:
>
> Demonstrate 80% utilization of their currently allocated space to qualify
> to receive one or more transfers up to the total size of their current ARIN
> IPv4 address holdings, with a maximum size of [/12 | /16], or
>
> Demonstrate the need for up to a 24-month supply of IP address resources
> under current ARIN policies.
>
> In section 8.4, replace:
>
> Recipients within the ARIN region must demonstrate the need for up to a
> 24-month supply of IPv4 address space.
>
> with:
>
> Recipients within the ARIN region must either:
>
> Demonstrate 80% utilization of their currently allocated space to qualify
> to receive one or more transfers up to the total size of their current ARIN
> IPv4 address holdings, with a maximum size of [/12 | /16], or
>
> Demonstrate the need for up to a 24-month supply of IPv4 address space
> under current ARIN policies.
>
> Comments:
>
> Timetable for implementation: immediate
>
> Anything else
>
> The [/12 | /16] notation for the cap is intended to offer some suggestions
> about what the cap should be. It is our intention that this will be
> replaced with a single value prior to this becoming a recommended draft.
>
> Notes on interaction with existing IPv4 assignment policy:
>
> Organizations requiring a transfer larger than a [/12 | /16] may either:
> transfer a [/12 | /16] at a time, and re-certify 80% utilization before
> receiving each new [/12 | /16], or continue to qualify under NRPM 4.2 or
> 4.3, which allows an organization to qualify for a 24-month supply of IPv4
> space via transfer. (That means, for example, that an organization that has
> used a /13 in less than a year would ordinarily qualify to receive a /12
> via transfer.)
>
> An organization holding a /22 and a /20 which are 80% utilized can qualify
> for one or more transfers over a two year period up to a /22 plus a /20 (up
> to 5120 IPs). After two years, or at any time that an organization wants
> more than the amount of transfer space approved, the organization can
> re-certify 80% utilization and get a new doubling window.
> _______________________________________________
> 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.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160525/ce9a47fb/attachment.htm>