Draft Policy 2011-1: Globally Coordinated Transfer Policy

[ARIN]

Draft Policy ARIN-2011-1
Globally Coordinated Transfer Policy

On 28 January 2011 the ARIN Advisory Council (AC) selected "Globally
Coordinated Transfer Policy" as a  draft policy for adoption discussion
on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in
April.

The draft was developed by the AC from policy proposal "ARIN-prop-119.
Globally Coordinated Transfer Policy". Per the Policy Development
Process the AC submitted text to ARIN for a staff and legal assessment
prior to its selection as a draft policy. Below the draft policy is the
ARIN staff and legal assessment, followed by the text that was submitted
by the AC.

Draft Policy ARIN-2011-1 is below and can be found at:
https://www.arin.net/policy/proposals/2011_1.html

You are encouraged to discuss Draft Policy 2011-1 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2011-1
Globally Coordinated Transfer Policy

Version/date: 23 December 2011

Policy statement:

Any RIR's resource registrant may transfer IPv4 addresses to the
resource registrant of another RIR as long as the two RIRs agree and
maintain compatible, needs-based transfer policies that exercise
Internet stewardship consistent with 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 by the ARIN Board of
Trustees


#####


STAFF ASSESSMENT

Proposal: Globally Coordinated Transfer Policy
Policy Version (Date): 23 December 2010
Date of Assessment:  10 January 2011

1. Proposal Summary (Staff Understanding)

This proposal would allow a registrant of IPv4 addresses from one RIR to
transfer those resources to a registrant (or future registrant) of
another RIR as long as both RIRs agree to the transfer, and apply
compatible, needs-based policies in accordance with the stewardship
principles expressed in RFC 2050.

2. Comments

   A.  ARIN Staff Comments

    1.  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.

    2. The staff would implement this policy in the following manner:

     a. For transfers from the ARIN region into another RIR region, ARIN
  would:
      o Confirm that the other RIR has "compatible, needs-based transfer
policies that exercise Internet stewardship consistent with the values
expressed in RFC 2050
      o Apply the relevant ARIN transfer policy criteria to the resource
registrant
      o Seek confirmation from the other RIR that the requesting
organization is physically located and has a verified legal presence in
the region
      o Closely coordinate with the other RIR, informing them when ARIN
is ready to complete the transfer
      o Complete transfer upon confirmation from the other RIR that the
recipient has met that RIR’s applicable transfer policies

     b. For transfers into the ARIN region from another RIR region, ARIN
         would:

      o Confirm that the other RIR has "compatible, needs-based transfer
policies that exercise Internet stewardship is consistent with the
values expressed in expressed in RFC2050"
      o Apply the relevant ARIN transfer policy criteria to the resource
recipient
      o Verify that the requesting organization is physically located
and has a verified legal presence in the region
      o Closely coordinate with the other RIR, informing them when ARIN
is ready to complete the transfer
      o Complete transfer upon confirmation from the other RIR that the
registrant has met that RIR’s applicable transfer policies
	
     3.  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

     4. The phrasing "to the resource registrant of another RIR" might be
made more accurate if the word “resource” was dropped and just the words
“to the registrant of another RIR” were retained. The recipient of a
resource transfer may not already have resources registered. This
rephrasing would make it clear that you have to be registered with the
RIR, but not necessarily be a current resource holder to utilize this
policy.

     5.  The text implies that the resources being transferred go
directly from Registrant>Recipient rather than from Registrant>RIR A>RIR
B>Recipient.  If the space gets transferred directly from registrant to
recipient without coming back to the RIR first, it is unclear which RIR
is ultimately authoritative for the space.

    B. ARIN General Counsel

     o First, 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 the requirement
that the resources be put under LRSA (or RSA) before they are transferred.
     o Second, in addition, I believe the word 'compatible' might better
be described as 'comparable'.
     o Third, don't we have to make the transfer to a specific registrant
'thru' the other RIR and not directly to that recipient from ARIN?

I made some other suggestions on language in caps for you to consider:
“Any RIR's resource [RSA OR LRSA] registrant may transfer IPv4 addresses
to a SPECIFIC resource registrant of another RIR, THRU THAT RIR, so long
as the RECEIVING RIR agrees to and maintains comparable, needs-based
transfer policies that exercise Internet stewardship consistent with the
values expressed in RFC2050.  NO TRANSFER MAY BE MADE TO AN RIR THAT
DOES NOT MAINTAIN COMPARABLE NEEDS-BASED TRANSFER POLICIES CONSISTENT
WITH THE VALUES IN RFC2050.”

As drafted this policy has no 'out': for example, it does not on its
face permit ARIN to refuse a transfer because the recipient is someone
who violates US or the recipient country's laws; or violates other ARIN
policies.  Do you want any flexibility built in to permit ARIN staff to
refuse an inter-region transfer if it would refuse an intra-region
transfer? I am not sure such a right to refuse is implied or could be
exercised.

3. Resource Impact

This policy would have minimal resource impact from an implementation
aspect.  It is estimated that implementation would occur within 3 months
after ratification by the ARIN Board of Trustees. However, maintaining
the policy is another matter and could require significant (human)
resources to carry out the potential increase in inter-RIR transfers.

The following would be needed in order to implement:

  • Updated guidelines
  • Staff training
  • Careful coordination between RIRs on reverse addressing issues

4. Proposal Text

Policy statement:

Any RIR's resource registrant may transfer IPv4 addresses to the
resource registrant of another RIR as long as the two RIRs agree and
maintain compatible, needs-based transfer policies that exercise
Internet stewardship consistent with the values expressed in RFC2050.

Rationale: Since individual RIRs now allow transfers, it makes sense to
be able to transfer between regions as well.