Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AFRINIC-rpd] IPv4 Address Allocation and Assignment proposal

Sunday Folayan sfolayan at gmail.com
Thu Jan 24 12:03:09 UTC 2013


Guy and Andrew,

Pardon my ignorance guys, but I need some clarification:

  1. a consumer requesting for PI space from the RIR must be 
multi-homed. True or false?
  2. Request for PI space must be made direct to the RIR not through an 
LIR. True or False?
  3. PA space must always be obtained from an LIR, not the RIR. True or 
False?
  4. An LIR must be an ISP? True or False?
  5. What additional demands do ISPs place on the RIR, which LIRs do not?
  6. Why is PI space sooo cheap globally, compared to PA Space?
  7. Apart from the Research and Education, what other sector needs PI 
space, who cannot pay for the mass of IP addresses required, just like ISPs?
  8. Beyond aggregating, what else is done to PA space that is not done 
to PI space?
  9. Am I the only one needing these answers?

Sunday.

On 24/01/2013 10:29, Andrew Alston wrote:
> 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
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>


-- 
--------------------------------------------------------
Sunday Adekunle Folayan
     blog: http://www.sundayfolayan.name.ng
    email: sfolayan at skannet.com.ng, sfolayan at gmail.com
    phone: +234-802-291-2202
    skype: sfolayan
     fcbk: www.facebook.com/sfolayan
    tweet: sfolayan
linkedin: sfolayan
---------------------------------------------------------




More information about the RPD mailing list