[ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region

[Marshall Eubanks]

On Tue, 30 Sep 2003 20:55:59 -0400
 Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Wed, Oct 01, 2003 at 01:02:52AM +0200, William Stucke
> wrote:
> > RIR		MIN SIZE	ELIGIBILITY
> > APNIC		/20		/22
> > RIPE		/20		/22
> > LACNIC	/20		/22
> > ARIN		/20		/20
> > 
> > In addition, in terms of "inter-registry policy coordination", RIPE
> > currently makes /22 allocations for their "Micro Members" and only requires
> > a demonstrated need for a /22, I believe. AfriNIC intends doing the same.
> > Why is ARIN out of step?
> 
> I've never thought to ask the question before, but I agree 100% that
> ARIN is out of step, and wonder why.
> 
> In a message written on Wed, Oct 01, 2003 at 01:47:07AM +0200, William Stucke
> wrote:
> > Africans, and AfriNIC members, are unanimous in supporting 2003-15. I
> > haven't heard a single African refuse to support 2002-3. I'm happy to
> record
> > my support for 2002-3 hereby, but do rather wonder why it's taken so long
> to
> > get through the system. I haven't heard a convincing argument that
> > supporting one will harm the other. Why, oh why, do (some few vocal) North
> > Americans refuse to support 2003-15?
> 
> I support 2002-3.  Actually, I supported several versions before
> it, and to this day think it should be both allocation and assignment.
> I believe you'll find a strong history of me supporting those
> efforts.

Dear Leo;

I have over the last year or so of this process talked to a number of 
small ISP's and small
multi-homers about micro-assignments. All of them feel that not having 
their own allocation is a hinderance on their business, and all of them
were excited to hear about 2002-3. None of them (except for me) were at all
active in the Arin / IETF standards setting process. When I asked why, they
cited time and money constraints, but most were not aware of it, or
thought of it as something that wasn't really open to them, and therefore not
worth their extremely limited resources. In blunter words, they thought it
would be a waste of time. I do not agree with this opinion, but it certainly
exists. Adoptation of 2002-3 offers an opportunity to refute it, and to better
serve an ARIN community that does not regard itself as well served.

I have not seen what I regard as strong technical justifications to not
adopt 2002-3, and its adoption would certainly be viewed positively by
the small provider community. Looking at 2003-15, which relaxes the smallest
address blocks to /22 for singly homed and /23 for multiply homed networks in
Africa, I would argue that 2002-3 would make the multiply homed part of 2003-15
irrelevant and suggest that the singly homed part of 2003-15 should be submitted
separately, so that the adoption time line would become 2002-3 now, a revised
2003-15 in the cycle after that if possible, to be followed by
a possible relaxation of 2002-3 to a /23 in the cycle after that.

So, in conclusion, 2002-3 addresses a good chunk of the concerns of the African
providers, while 2003-15 addresses none of the concerns of small non-African
providers. I strongly supported the adoption of 2002-3 and am trying to
rearrange my schedule to be in Chicago. I can only support 2003-15 to the
extent that it does not interfere with the adoption of 2002-3.

Regards
Marshall Eubanks

> 
> Part of what bothers me here is that 6 or 12 months ago when 2002-3
> discussion was going on I don't recall many (or any, really) of the
> "Africa People" who have been supporting 2003-15 stepping up to
> voice their support.  There were proposals for a policy that did
> exactly what African's seem to want, and the 2002-3 proposal (which
> seems to not include assignments and allocations as desired), and
> yet no one came forward to help.
> 
> Now that we're getting some traction on 2002-3, we're sidetracked
> by this Africa proposal.  At least two people have responded on
> list when I asked them to support 2002-3 instead (or Owen asked,
> as amended) that they felt 2003-15 had a better chance of passing,
> so they just wanted the local policy.  My inference was that they
> felt 2002-3 would be defeated because the "big bad backbones" in
> the US would never let it happen here, but they might be indifferent
> enough to let Africa get away with it.
> 
> Indeed, that is somewhat my worry as well.  It is possible that
> 2003-15 would pass, and that people would use it passing to support
> defeating 2002-3.  I can think of a half dozen excuses (some of
> which have already been posted on the list) that might be used to
> support that line of thinking.
> 
> There is a real problem that having both proposals in the system
> will split the vote.  I think the discussion here only supports
> that conclusion.  Clearly people have strong opinions one way or
> the other, and I see no clear majority.  The only way to win is to
> not split the vote, joining up and outvoting the "big bad backbones".
> 
> Now, if we're going to join forces, it's going to be behind 2002-3,
> or a new proposal that is global, and includes allocations and
> assignments.  We're not going to join forces behind 2003-15, because
> it applies only to Africa, so for the people who've been working
> to get this in the US for some time now that would do absolutely
> no good.
> 
> It is for this reason I would ask the African contingent to withdraw
> 2003-15, and either support 2002-3, or if having both types of
> membership is important draft a new proposal that is global and has
> both assignments and allocations.
> 
> As long as we have both we're going to get bogged down in the
> global-vs-local us-vrs-africa big-bad-backbone-vrs-small-nice-guy
> wars and never win.  There are some valid opinions and some invalid
> opinions on both sides in each of those discussions, let's just avoid
> them, work together, and get something that actually helps _all_
> of us.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org