[ppml] 2002-02 Address space allocations for experimental pur poses

Thomas Narten narten at us.ibm.com
Tue Apr 8 07:47:29 EDT 2003

I have some comments on this proposal.

> 2002-2: Experimental Internet Resource Allocations

> There have been a number of experimental address allocations
> undertaken in the Internet over the past decade. These experimental
> address allocations have been made by the IANA in coordination with
> the IETF, on an ad hoc basis. There is currently no systematic means
> of receiving other Numbering Resources on a temporary basis as part of
> a recognized experiment in Internet technology deployment. The
> following policy is proposed:

Note: I'm assuming "experiment" means an experiment in the sense of
trying some new technology where what is needed is something other
than "global unicast address space", for which existing processes are
already in place within the RIRs for obtaining such space.

> ARIN will allocate Numbering Resources to entities requiring temporary
> Numbering Resources for a fixed period of time under the terms of
> recognized experimental activity.

High-level. If IANA has been making experimental allocations in the
past, what problem needs fixing? Why is a change needed? I would think

1) experimental allocations are not a regional RIR issue, and we would
   want uniform review of requests (as opposed to per RIR
   review). This makes me wonder why an RIR needs to take this on as
   something they would support.

2) if ARIN (or any RIR) felt they needed to do this, there would need
   to be way to coordinate review of these proposals in a broader
   context. This includes among the RIRs and the IETF. I see nothing
   in this proposal that addresses inter-RIR coordination. This seems
   a shortcoming.

3) Jumping ahead to the another part of the document:   

> 7. Resource Allocation Size

> The Numbering Resources requested come from the global Internet
> Resource space, and are not from private or other non-routable
> Internet Resource space. The allocation size should be consistent with
> the existing ARIN minimum allocation sizes, unless small
> allocations are intended to be explicitly part of the experiment. If
> an organization requires more resource than stipulated by the minimum
> allocation sizes in force at the time of their request, their
> experimental documentation should have clearly described and justified
> why this is required.

I see absolutely no reason why an experimental allocation of size X
(where X is defined by the experiment) should be shoehorned into the
current default minimum allocation size. Indeed, the allocation should
be for precisely the amount of space that is needed, to minimize
abuse. E.g., if an experiment finds out it needs more space than the X
it originally envisioned (and justified), shouldn't any increase in
this amount also be re-reviewed? Not doing so would seem inconsistent
with the point of Section 5.

I think this points out to a broader issue. IANA is already in a
position to make special assignments (of arbitrary) size and perhaps
even out of particular address space that has NOT been allocated to
the RIRs (e.g., out side of 001). That is, by definition, an
experiment is something different than normal IP, so it is unclear to
me whether or not experimental allocations should always be allocated
out of "routable" space as the above says it must.  It seems to be
like IANA should retain control of the management of experimental

Also how would RIR-specific allocations for experimental use interact
with the sparse allocation procedure discussed during today's meeting
(RIPE 261: IPv6 Address Space Management). A large allocation could
interfere with this algorithm.

> 1. Documentation of recognized experimental activity

> A Recognized Experimental Activity is one where the experiment's
> objectives and practices are described in a publicly accessible
> document. It is a normal requirement that a Recognized Experimantal
> Activity also includes the undertaking that the experiment's outcomes
> also be published in a publically accessible document.

One other critical requirement. Is the experiment actually an
experiment? In particular, will the experiment clearly terminate, and
can the address space be returned at the end of the experiment
(regardless of the outcome of the experience)? I'm worried about
end-runs around the normal allocation process; there are experiments
that involve getting software deployed where you can't in practice get
it turned off or recalled once the "experiment" is supposed to
end. Any evaluation of the experiment must verify that a proposed
experiment will actually end cleanly.

> ARIN has a strong preference for the recognition of experimental
> activity documentation in the form of a document which has achieved
> "IETF consensus" as described in RFC 2434.

I think this is a good direction to go in. Personally, I think any
experiment that requires a chunk of address space absolutely requires
an IETF review. Indeed, it needs a rather broad review to ensure the
experiment won't harm the internet and will terminate in a fixed
amount of time. But what does it mean for ARIN to have "a strong
preference" for going this route? The bottom line will be what happens
when ARIN gets a request where the requestor doesn't want to do
this. What happens then? (Why would a requestor not want to go the
IETF route? Perhaps, they have come to ARIN on the hopes that the
review will be less rigorous, e.g., after having been turned away by
the IETF.)

If ARIN really "strongly prefers" that experimental activity be
documented in an RFC per above, the straightforward way to achieve
this would be to simply adopt the policy that experimental allocations
are only done for experiments documented through IETF processes.

> 2. Technical Coordination

> ARIN requires that a recognized experimental activity is able to
> demonstrate that the activity is technically coordinated.

>     Technical coordination specifically includes consideration of any
>     potential negative impact of the propsed experiment on the
>     operation of the Internet and its deployed services, and
>     consideration of any related experimental activity.

> ARIN will review planned experimental activities to ensure that they are
> technically coordinated.  This review will be conducted with ARIN and/or
> third-party expertise and will include liaison with the IETF.

Definitely, experimental allocations need broad review. I'm worried
that the above wording isn't strong enough. It isn't specific enough
about what level of review will actually be achieved.

> 3. Coordination over Resource Use

> When the IETF's standards development process proposes a change in the
> use of Numbering Resources on an experimental basis the IETF should
> use a liaison mechanism with the Regional Internet Registries (RIRs)
> of this proposal. The RIRs will jointly or severally respond to the
> IETF using the same liaison mechanism.

Hmm. I worry that the liaison channel will be too formal and narrow. I
think the liaison process can be good for pointing out that a
particular experiment is being considered and providing a "heads up"
that an activity needs to be followed up on. But the input should go
through more typical channels. E.g, if the IETF has a Last Call on the
document, the RIR community could provide input directly through that
process. Having the RIR response go through the liaison raises the
problem that the RIRs will likely have to speak with a single voice
(which is odd, since there is no requirement from what I can see that
the RIRs need to speak with one voice with regards to a proposal they
are evaluating just by themselves). If they speak with one voice, any
feedback is likely to be narrow and specific, rather than reflecting
the full range of input that one might expect from the RIR community.


More information about the ARIN-PPML mailing list