[AFRINIC-rpd] IPv4 Address Allocation and Assignment proposal

[Andrew Alston]

You aren't alone :)

Andrew


-----Original Message-----
From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On Behalf Of
Guy Antony Halse
Sent: Thursday, January 24, 2013 11:09 AM
To: sm+afrinic at elandsys.com
Cc: rpd at afrinic.net
Subject: Re: [AFRINIC-rpd] IPv4 Address Allocation and Assignment proposal

Hi

On Wed 2013-01-23 (06:57), sm+afrinic at elandsys.com wrote:
> How about:
> 
> An end site is an entity which does not make sub-allocations, 
> allocations, or re-assignments, and which uses any IP address space 
> assigned to it either within the entity or as part of its internal
operations.

The problem with this, as with other drafts, is that it assumes that the
distinction between end user/end site and LIR is *completely* black and
white.

Consider the following hypothetical situation:

I run the internal network for a large, for-profit company.  We want to dual
home, so we apply for PI address space.  At this stage we meet the above
definition, and thus we apply as an "end site".  We have two ISPs, and
everything is great.

Some time later, perhaps as part of a corporate social responsibility
programme, we lease a small NGO a single office in our building.  Although I
use the word "lease" (because an agreement exists, and they are a separate
legal entity), no money exchanges hands.  We do it because it is the right
thing(tm) to do.

The NGO then asks if we could possible give them Internet access.  We decide
that because the impact will be minimal on our operations, we can do so.  We
allocate them a subnet from our network, and use this to provide them with
Internet access free of charge.  Again it is the right thing(tm) to do. 
They use less than 1% of our assigned address space, and virtually no
bandwidth.

At this stage we technically no longer meet the definition above; we are now
technically an LIR because the the space is not used internally any more and
because we've made a single, very small sub-allocation.

Assuming we're honest about it, in terms of AfriNIC's cost structures and
this policy, things change:

 - 8.5 requires I register the allocation with AfriNIC;

 - I am now subject to the requirements of sections 8 through 10;

 - The fees due to AfriNIC increase (outside the scope of this policy, but
   relevant to the discussion).

Our management decides that the additional cost and administrative burden
this imposes it too onerous and cannot be justified.  It was fine when we
were just running a UTP cable through the wall, but now we have to complete
paperwork and spend (recurring) money.  Thus we have two choices:

 a) lie (perhaps tacitly, by simply not telling) to AfriNIC.  This carries
    the risk we'll be caught, and lose our assignment (per 6.1); or

 b) cease providing the NGO with Internet access.

Neither of these are desirable outcomes.


Back in the real world we live in, I don't think that the above example is
that uncommon.  I can think of several (real) examples in South Africa, and
I'm sure there are others elsewhere in Africa.  Africa is not like Europe or
the Americas -- Internet access still isn't easy to get, particularly if
you're a small organisation with limited financial resources (viz an NGO or
government-funded school).

IMHO seeing this problem as completely black & white helps perpetuate a
growing digital divide.  In Africa, where Internet penetration is low,
policies should /facilitate/ things like the above rather than preclude
them; they should allow large corporate (and universities!) to help those
who otherwise would not have access to the Internet.

Thus I'm really opposed to any definition of "end user" or "end site" that
doesn't allow /some/ flexibility for the grey areas.  I'm happy if this
flexibility is formally qualified in policy -- appropriate restrictions
include limitations on the amount of address space ("no more than 10%"),
they type of organisation or relationship ("not-for-profit"), or whether or
not this is how I make money or why I exist ("core business").


If I'm alone in thinking this is a problem, let me know and I'll shut up
about it ;-).

- Guy
--
Manager: Systems, IT Division, Rhodes University, Grahamstown, South Africa
Email: G.Halse at ru.ac.za   Web: http://mombe.org/   IRC: rm-rf at irc.atrum.org
*** ANSI Standard Disclaimer ***                                    J.A.P.H
_______________________________________________
rpd mailing list
rpd at afrinic.net
https://lists.afrinic.net/mailman/listinfo.cgi/rpd