[arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7

[Dani Roisman]

I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs).  When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support.

I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now.  The ARIN AC and membership needs to hear views of not only those opposed to this proposal.

----
Dani Roisman


| -----Original Message-----
| Date: Wed, 17 Feb 2016 00:12:54 +0000
| From: Leif Sawyer <lsawyer at gci.com>
| To: ARIN PPML <arin-ppml at arin.net>
| Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based
| 	evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks
| Message-ID:
| 	<EDF941B230F4C446826CF893A9C8CE59E0DBF413 at ex-mbx-
| prd02.gci.com>
| Content-Type: text/plain; charset=WINDOWS-1252
| 
| 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.
| 
| 
|