+1 — McTim said it very well. Owen
> On Feb 18, 2016, at 10:34 , McTim <dogwal...@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 <lsaw...@gci.com > <mailto:lsaw...@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 > <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@arin.net > <mailto:ARIN-PPML@arin.net>). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > <http://lists.arin.net/mailman/listinfo/arin-ppml> > Please contact i...@arin.net <mailto:i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
