[ppml] Policy Proposal 2007-23 - Staff Assessment

Policy Proposal 2007-23
End Policy for IANA IPv4 allocations to RIRs

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_23.html

II. Understanding of the proposal

ARIN staff understands that this policy would have IANA allocate a
single /8 to each of the 5 RIRs at the point when the IANA free pool
hits 5 /8s.

III. Comments

   A. ARIN Staff

     1. Item 3 indicates that the RIRs will project an IANA exhaustion
date. The RIRs do not generally make projections about address space,
and in particular, about the IANA pool since they have no control over
these resource.

     2. The policy conflicts with the spirit of RFC 2050 in which
fairness and efficiency of allocation by IANA to the RIRs is cited.

     3. Author did not indicate placement in the NRPM. It would go in to
Section 10.

   B. ARIN General Counsel

"These two policies address the same issue, the global policy of what
allocation should be made and when regarding the last un-issued IPv4
slash 8's from the IANA. Based on legal considerations counsel has
serious concerns about the implications of adopting 2007-18. Counsel
does not have similar concerns about 2007-23.

2007-23 describes a policy to allocate equally the last 5 blocs of
un-issued slash 8's, providing one each to each of the 5 RIR's. This is
a rationing mechanism to allocate the last slash 8's.

2007-18 describes much more aggressive policy which would allocate the
last 25 such blocs equally, providing 5 each to each RIR.
The first policy proposal, 2007-23, is more consistent with the current
legal underpinnings of the RIR system, while 2007-23 substitutes a new
basis of allocation, equality between RIRs, who have very different
rates of utilization and need. The substitution of utilizing RIR
equality instead of a utilization based allocation may have significant
legal implications for ARIN.

Currently, if ARIN is legally challenged about its allocation policies,
and the underlying global policy, all current policies are based in need
and utilization. Since the takeup rate in each RIR is very different the
allocation policy proposed in 2007-23 undermines the current rationale
of need and utilization based allocation, and it is inconsistent with
all prior ARIN and global allocation policies.

Adoption of 2007-23 discriminates against the ARIN service region and
could reduce the amount of IPv4 resources available and instead shift
these resources to other continents, with less actual need than the ARIN
region. This will, in my opinion, raise fiduciary responsibility issues
for ARIN's Board, and may lead to counsel cautioning the Board members
regarding adoption of global policy that has an intentionally
discriminatory impact against or adverse to ARIN's service region."

Resource Impact – Minimal

The resource impact of implementing this policy is viewed as minimum.
Barring any unforeseen resource requirements, this policy could be
implemented within 30 -90 days from the date of the ratification of the
policy by the ARIN Board of Trustees.  It will require the following:

-  Updates to Guidelines will be required
-  Staff training will be required

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-23
End Policy for IANA IPv4 allocations to RIRs

Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA, Akira
NAKAGAWA, Izumi OKUTANI, Kosuke ITO, Kuniaki KONDO, Shuji NAKAMURA,
Susumu SATO, Takashi ARANO, Tomohiro FUJISAKI, Tomoya YOSHIDA, Toshiyuki
HOSAKA

Proposal type: new

Policy term:renewable

Policy statement:

1) Distribute a single /8 to each RIR at the point when new IANA free
pool hits 5 */8. This date is defined as "IANA Exhaustion Date".

2) It should be completely left up to each RIR communities to define a
regional policy on how to distribute the remaining RIR free pool to LIRs
within their respective regions after "IANA Exhaustion Date".

Note 1: It is fine for an RIR to continue operations with the existing
policy if that is the consensus decision of the respective RIR community.

Note 2: Address recovery and re-distribution of recovered address space
is another important measure for considerations, but should be treated
as a separate policy proposal from distribution of new IANA pool.

3) RIRs should provide an official projection on IANA Exhaustion Date to
the community through their website, at their Policy Meetings and
through any other effective means.

Rationale:

[current problem]
There are two major issues in terms of address management if no measures
are taken for IPv4 address exhaustion.

1) Continue applying a global coordinated policy for distribution of the
last piece(s) of RIR's unallocated address block does not match the
reality of the situation in each RIR region.

Issues each RIR region will face during the exhaustion period vary by
region as the level of development of IPv4 and IPv6 are widely
different. As a result, applying a global co-ordinated policy may not
adequately address issues in a certain region while it could be work for
the others.

For example, in a region where late comers desperately need even small
blocks of IPv4 addresses to access to the IPv4 Internet, a policy that
defines the target of allocations/assignments of IPv4 address space to
be late comers would be appropriate in such region. This would allow
availablilty of IPv4 address space for such requirements for more years.

Another example comes from difference in IPv6 deployment rate. For a
region where IPv6 deployment rate is low, measures may be necessary to
prolong IPv4 address life for the existing business as well as for new
businesses until networks are IPv6 ready. Some regions may have strong
needs to secure IPv4 address space for translators.

A globally coordinated policy which addresses all the issues listed
above to meet the needs for all RIR regions may result in not solving
issues in any of the regions.

2) LIRs and stakeholders remain unprepared for the situation if they are
not informed

If LIRs and the community are uninformed of the exhaustion, their
services and networks remain unprepared to face the situation at the
time of exhaustion.



[Objective of the proposal]
This proposal seeks to provide the following solutions to the problems
listed above.

1) RIR community should be able to define their own regional policies on
how to assign the last piece(s) of allocation block in order to address
their own regional issues during the exhaustion period.

2) RIRs should provide official projection of the date when LIRs will be
able to receive the allocations under the current criteria. The criteria
should remain consistent until this date in order to avoid confusion.



[Pros and Cons]
Pros: + It allows each RIR community to define a policy on how to
distribute the last piece(s) of allocations which best matches their
situation.

+ It helps LIR better informed of the date when they are able to receive
allocations from RIRs under the current criteria and prepare for the event.

Cons: + Concerns could be raised about allocating a fixed size to all
RIRs, that it artificially fastens the consumption rate of some RIR
regions. However, its impact is kept to minimum by keeping the
allocation size to a single /8 which makes merely 3-4 months difference.

+ Concerns could be raised that explicitly allowing regional policies
will encourage RIR shopping. However, this should not happen if the
requirements within each region is adequately reflected in each RIR's
policy through PDP. RIR may also chose to add criteria to prevent LIRs
from other regions submitting such requests.

Timetable for implementation: Immediate after all 5 RIRs (and possibly
ICANN) ratifies the policy.