[arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers - revised

[Jeffrey Lyon]

Opposed. There is substantial need for IPv4 at every RIR. One is not
more important than the other, so there should never be a policy
permitting a transfer out.

Jeff


On Thu, Sep 22, 2011 at 2:29 PM, ARIN <info at arin.net> wrote:
> Draft Policy ARIN-2011-1
> ARIN Inter-RIR Transfers
>
> ARIN-2011-1 has been revised. This draft policy is open for discussion
> on this mailing list and will be on the agenda at the upcoming ARIN
> Public Policy Meeting in Philedelphia.
>
> ARIN-2011-1 is below and can be found at:
> https://www.arin.net/policy/proposals/2011_1.html
>
> Following the text is an ARIN staff assessment.
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2011-1
> ARIN Inter-RIR Transfers
>
> Date: 22 September 2011
>
> Policy statement:
>
> Address resources may be transferred in or out of the ARIN region to those
> who demonstrate need and plan to deploy them for a networking purpose within
> 3 months. Such transfers will take place between RIRs who share compatible,
> needs-based policies supporting entities agreeing to the transfer and which
> otherwise meet both RIR's policies. Transferred resources will become part
> of the resource holdings of the recipient RIR unless otherwise agreed by
> both RIRs.
>
> Rationale: Since individual RIRs now allow transfers, it makes sense to be
> able to transfer between regions as well. Reasoning....It is explicit
> about...
>
> in or out of region,
> that transfers are between RIRs that support needs-based policies,
> that RIRs have to agree,
> that parties meet all of both RIR policies
> that it is needs based, and the need is for a networking purpose,
> that the receiving RIR is entitled to the addresses
>
> I think all these details were raised as objections at one time or
> another...so it seems best to waste a few more words to be explicit.
>
> It is not explicit about...
> block sizes
> utilization of prior allocations,
> assignments or transfers
> RFC 2050
> subsequent transfers
>
> Timetable for implementation: Upon ratification by the ARIN Board of
> Trustees
>
>
> #####
>
>
> ARIN Staff Assessment
>
> Draft Policy:  2011-1 ARIN Inter-RIR Transfers
>
> 1.  Proposal Summary (Staff Understanding)
>
> This proposal would allow transfers of address space to and from the ARIN
> region as long as both RIRs agree to the transfer, and apply compatible,
> needs-based policies.
>
> 2. Comments
>
> A. ARIN Staff Comments
>
> •       The proposed policy language is unclear, vague, and is wide open for
> interpretation.
>
> •       The key phrase, "compatible, needs-based policies" is undefined.
> While many in the ARIN PPML community understand the intent of the phrase,
> it is really important that policy text be clear and understandable to all.
> •       The phrase, "which otherwise meet both RIR's policies" is also
> vague. Which policies must the transferor and transferee meet? The text
> should be revised to be precise to fully convey the author's intent.
>
> •       Note that the proper possessive of "RIR's policies" should be "RIRs'
> policies".
>
> •       The last sentence says, " Transferred resources will become part of
> the resource holdings of the recipient RIR unless otherwise agreed by both
> RIRs”.  It is constructed so that it basically says “It will be this, unless
> you want that."   This isn't definitive policy text and should be clarified.
>
> •       This policy seems to directly contradict NRPM 8.3, Transfers to
> Specified Recipients, which disallows IPv4 number resources to be
> transferred outside of ARIN’s region.  Without a change to NRPM 8.3, ARIN
> would only be able to apply NRPM 8.2, Mergers and Acquisitions when
> reviewing inter-RIR policies.
>
> •       The staff would implement this policy in the following manner:
> •       For transfers from the ARIN region into another RIR region, ARIN
> would:
> •       Confirm that the other RIR has "compatible, needs-based policies
> •       Apply the relevant ARIN transfer policy criteria to the resource
> registrant
> •       Seek confirmation from the other RIR that the requesting
> organization is physically located and has a verified legal presence in
> the region
> •       Closely coordinate with the other RIR, informing them when ARIN
> is ready to complete the transfer
> •       Complete transfer upon confirmation from the other RIR that the
> recipient has met that RIR’s applicable transfer policies
>
> •       For transfers into the ARIN region from another RIR region, ARIN
> would:
> •       Confirm that the other RIR has "compatible, needs-based
> policies
> •       Apply the relevant ARIN transfer policy criteria to the resource
> recipient
> •       Verify that the requesting organization is physically located
> and has a verified legal presence in the region
> •       Closely coordinate with the other RIR, informing them when ARIN
> is ready to complete the transfer
> •       Complete transfer upon confirmation from the other RIR that the
> registrant has met that RIR’s applicable transfer policies
>
> •       The previous version of this proposal limited these transfers to
> IPv4 space while this version does not.  Was that an oversight or did the
> author intend to have this policy apply to both IPv4 and IPv6 addresses?
>
> •       This proposal allows the transfer of any IPv4 resource, whether
> it be Legacy/ERX address space or address space that was directly
> delegated to the RIR by IANA. Allowing the transfer of directly
> delegated number resources between RIRs could cause a variety of issues
> including:
> • Zone fragmentation
> • DNS synchronization problems
> • Potential administrative and operational issues in coordinating
>   reverse addressing
>
> B. ARIN General Counsel
>
> 1.  I suggest one major addition to this policy, which may be totally
> consistent with the drafter's intent. Currently, it is my understanding that
> ARIN policy does not permit transfers within the region unless the resources
> are covered by RSA or LRSA. The language of this section might properly be
> clarified to reinforce that resources not already under registration
> services agreement may not be transferred until ARIN has validated the
> correct resource holder
>
> 3. Resource Impact
>
> This policy would have major resource impact from an implementation aspect.
>  It is estimated that implementation would occur within 9-12 months after
> ratification by the ARIN Board of Trustees. The following would be needed in
> order to implement:
>
> •       Careful coordination between the RIRs on DNS issues and updates
> •       Updated guidelines
> •       Staff training
>
>
>
> _______________________________________________
> 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.
>



-- 
Jeffrey Lyon, Leadership Team
jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions