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

[John M. Brown]

RIR's want to do this because they want to be the IANA, at least
for ASN's and IP's..

RIR's wish to take as much control away from IANA, because of the
letters ICANN.  ICANN should be left with letters, not numbers.

RIR's don't believe they are child orgs to IANA, not since Postel
passed away......

I do happen to agree that IANA is the proper and RIGHT place
for experimental allocations.  It would be better received
in the community if ICANN would get a proper CTO.   But thats
a different conversation....

just my $o dot A worth

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Thomas Narten
> Sent: Tuesday, April 08, 2003 5:47 AM
> To: Geoff Huston
> Cc: ppml at arin.net
> Subject: Re: [ppml] 2002-02 Address space allocations for 
> experimental pur poses 
> 
> 
> 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
> that:
> 
> 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 allocations.
> 
> 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.
> 
> Thomas
>