[arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks

[Jason Schiller]

+1 to what MCTim, Owen, and Vaughn said.

In general I oppose transfers with no need.

If there are "networks in need of additional IPv4 addresses", surely they
should be able to show this, in accord with long standing practice.

I'd rather us not move to a situation which enables/encourages speculation
and profit taking (or rent-seeking if you will) in re: IP resource
distribution.

I'd also rather not encourage one competitor in a business segment to be
able to better stockpile addresses and for that to become a competitive
advantage
against other providers in the space.  Additionally if this is done in a
wide enough scale it can sufficiently lengthen wide spread IPv6 adoption.

This policy would also allow for companies with the deepest pockets and the
most profitable services to concentrate IPv4 space.  I'm not sure that is
more "fair"
than the pre-existing framework for "fair".

__Jason



On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems <
vaughn at swiftsystems.com> wrote:

> +1
>
> Sent from my mobile device, please forgive brevity and typos.
>
> On Feb 18, 2016, at 2:16 PM, Owen DeLong <owen at delong.com> wrote:
>
> +1 — McTim said it very well.
>
> Owen
>
> On Feb 18, 2016, at 10:34 , McTim <dogwallah at gmail.com> wrote:
>
> I am opposed.
>
> If there are "networks in need of additional IPv4 addresses", surely they
> should be able to show this, in accord with long standing practice.
>
> I'd rather us not move to a situation which enables/encourages speculation
> and profit taking (or rent-seeking if you will) in re: IP resource
> distribution.
>
> Regards,
>
> McTim
>
>
> On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer <lsawyer at gci.com> wrote:
>
>> Good afternoon -
>>
>>   Based on feedback from Montreal as well as internal discussions, I've
>> reworked this policy.
>> AC members and ARIN staff are looking for additional feedback, as well as
>> your position in terms
>> of supporting or opposing this draft policy.
>>
>>   We'll be discussing this policy, as well as any feedback provided on
>> this week's AC teleconference,
>> so I'm very appreciative of your input.
>>
>> Thanks,
>>
>>   Leif Sawyer
>>   Shepherd - ARIN-2015-9
>>
>> NRPM section 8: https://www.arin.net/policy/nrpm.html#eight
>>
>> Most current draft policy text follows:
>> --
>>
>> Draft Policy ARIN-2015-9
>>     Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers
>> of IPv4 netblocks
>> Original Date: 23 September 2015
>> Updated: 16 February, 2016
>>
>> Problem statement:
>> The current needs-based evaluation language in NRPM sections 8.2 and 8.3,
>> regarding transfer of IPv4
>> netblocks from one organization to another, may cause a recipient
>> organization to bypass the ARIN
>> registry entirely in order to secure the needed IPv4 netblocks in a more
>> timely fashion directly from the
>> current holder. The result is that the data visible in ARIN registry may
>> become more inaccurate over
>> time.
>>
>> Policy statement:
>> This proposal eliminates all needs-based evaluation language for sections
>> 8.2 and 8.3, allowing
>> transfers to be reflected in the database as they occur following an
>> agreement of transfer from the
>> resource provider to the recipient.
>>
>> Section 8.1 Principles:
>> - Strike the fragment from the 3rd paragraph which reads
>>         ", based on justified need, "
>> so the resulting text reads
>> "Number resources are issued to organizations, not to individuals
>> representing those organizations."
>> Section 8.2 Mergers and Acquisitions:
>> - Change the 4th bullet from:
>> "The resources to be transferred will be subject to ARIN policies."
>> to:
>> "The resources to be transferred will be subject to ARIN policies,
>> excluding any policies related to needs-based justification."
>>
>> - Strike the final paragraph which begins "In the event that number
>> resources of the combined organizations are no longer justified under ARIN
>> policy ..."
>>
>> Section 8.3 Transfers between Specified Recipients within the ARIN Region:
>> - Change the first bullet under "Conditions on recipient of the transfer"
>> from:
>> "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."
>> to:
>> "The recipient must sign an RSA."
>>
>> - Change the 2nd bullet under "Conditions on recipient of the transfer"
>> from:
>> "The resources to be transferred will be subject to ARIN policies."
>> to:
>> "The resources to be transferred will be subject to ARIN policies,
>> excluding any policies related to needs-based justification."
>>
>> Comments:
>> a. Timetable for implementation: Immediate
>> b. Anything else
>> As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and
>> ARIN) have now been
>> exhausted, networks in need of additional IPv4 addresses have shifted
>> away from the practice of
>> receiving them from the RIR's resource pool. Instead, networks in need
>> are seeking out current holders
>> of IPv4 resources who are willing to transfer them in order to fulfill
>> that need. Accordingly, the RIR's
>> primary responsibility vis-à-vis IPv4 netblock governance has shifted
>> from "allocation" to ensuring an
>> accurate registry database.
>>
>> The RIPE registry can be used as a reference of one which has evolved
>> over the past couple years to
>> shift their focus away from conservation/allocation and towards database
>> accuracy. IPv4 netblock
>> transfers within that RIR consist merely of validating authenticity of
>> the parties requesting a transfer.
>> Provided the organizations meet the basic requirement of RIR membership,
>> and that the transferring
>> organization has the valid authority to request the transfer, the
>> transaction completes without any
>> "needs-based" review.
>>
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> Cheers,
>
> McTim
> "A name indicates what we seek. An address indicates where it is. A route
> indicates how we get there."  Jon Postel
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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/20160218/92c4d574/attachment.htm>