ICANN ICANN Email List Archives

[aso-ipv4-policy]


<<< Chronological Index >>>    <<< Thread Index >>>

Comment on Policy for Allocation of IPv4Blocks to Regional Internet Registries

  • To: aso-ipv4-policy@xxxxxxxxx
  • Subject: Comment on Policy for Allocation of IPv4Blocks to Regional Internet Registries
  • From: Ron Wickersham <rjw@xxxxxxxxxxx>
  • Date: Tue, 22 Mar 2005 16:38:19 -0800 (PST)

This policy does not enforce or support the RFCs for allocation to end-
users of IPv4 address space.

The tone of this document is to completely trivialize any oversight by
IANA (or ICANN) on the actual operation of RIRs and should not be
adopted as it now stands.

The first paragraph should state the goals of the policy which must
include the requirement for RIRs to adhere to RFCs so that end-user
allocation policies are fairly applied in all geographic regions.

In Section 1, the Allocation Principles again must state that the RIRs
will only qualify for additional space if they have followed good
stewardship of already allocated address space.   The IANA should not
give up it's authority under the stated terms of this policy since
there is no other check and balance mechanism in place.

   The first bullet for /8 units is ok, and in the spirit of RFCs.
   The second bullet has no justification.  ICAN delegations are
       effective immediately, so there is no need for long-lead
       allocations in the real world.
   The third bullet is completely unacceptable.  The RIRs must be
       held accountable in the larger world space and not turned
       loose to set policies that are not in accordance with the
       common good.

In Section 2, there is no justification given for the initial
   allocation, which the language states should be given expressly
   even when there is no concieveable need for a large block.

In Section 3, the first bullet is bad policy, and a time frame for
   exhaustion of the remaining available space should be part of
   the policy.
   The second bullet would be better served with a 6 months time
       frame, again because there is no need for advance allocation
       since the space is immediately usable when IANA allocates it.

In Section 3.2, the necessary space formula is somewhat ambiguous
   in the final factor "length of period in months" which is implied
   to be 9 months from the second bullet in Section 3, so if that
   is the case then the formula can be better stated as "total
   number of addresses allocated during the last 6 months / 4".

Note that the last paragraph of Section 3.2 surprisingly adds back
a bit of ovesight but only for "special needs" and puts the burden
of proof on IANA rather than on the RIR.   But IANA has no staff
for this oversight, so would have to rely of outside volunteers to
bring facts to its attention and since the publication of the requests
are not anticipated the entire "special needs" section should be
omitted.

In Section 4, IANA will prepare a detailed announcement.  However
the last paragraph states that IANA will not make that announcement
public.   This means that this policy statement is giving additional
constraint to IANA to keep this information secret.    This should
be reversed, and the IANA should be required to make the detailed
announcement public.   Transparancy in internet governance by ICANN
and its departments such as IANA is already required so this paragraph
is in contradiction to other ICANN policies.

###

Summary:  I believe that the policy as drafted is unacceptable.  While
it may be argued that the performance requirements of IANA allocation
be reduced to agreements that may come forth, it is inappropriate to
strip the only oversight currently in place before such separate,
concensus based discussion and agreements are in place.  Is clearly
contrary to the public interest and good internet governance.

-ron

Ron Wickersham


<<< Chronological Index >>>    <<< Thread Index >>>