[arin-ppml] Policy Proposal 119: Globally Coordinated Transfer Policy
On 10/11/2010 10:20 AM, ARIN wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
> The AC invites everyone to comment on the proposal on the PPML,
> particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> Draft Policies and Proposals under discussion can be found at:
> The ARIN Policy Development Process can be found at:
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> ## * ##
> Policy Proposal 119: Globally Coordinated Transfer Policy
> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
> Proposal Version: 1.0
> Date: 11 October 2010
> Proposal type: new
> Policy term: permanent
> Policy statement: Any RIR's member may transfer IPv4 addresses to the
> member of another RIR as long as the two RIRs agree and exercise
> Internet stewardship and the values expressed in RFC2050.
> Rationale: Since individual RIRs now allow transfers, it makes sense to
> be able to transfer between regions as well.
> Timetable for implementation: upon ratification of all five RIRs
> Timetable for de-implementation: upon change to this policy text in any RIR
I disagree with the specific implementation but agree with the general
thrust of it. I would prefer that any globally coordinated transfer
policy such as this would do the following:
1) explicitly set a minimum size of the block. RFC's can be superseded.
And we do not want a lot of bifurcation of the ownership of the blocks.
/9's. /10's, I can see. But as you get smaller and smaller the reasons
for allowing this rapidly get fuzzier and fuzzier.
2) Mandate that the transfer is RIR-to-RIR. The correct verbage would
be something along the lines of:
Any RIR's member may request their RIR to permit an IPv4 address
transfer of their IPv4 to another RIR that is earmarked for assignment
to a member of that RIR.
3) I also want to see an expiration if the transfer fails. The verbage
would be something like:
In the event that the directed assignment fails due to the receiving
RIR rejecting the assignment, the earmark will expire in 6 months and
the addresses will revert to the original RIR