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

[AfriNIC-rpd] Updated Version of the "IPv4 Soft Landing Policy"now Available Online

Andrew Alston aa at tenet.ac.za
Thu Feb 24 08:30:17 UTC 2011




On 2011/02/24 9:27 AM, "Owen DeLong" <owen at delong.com> wrote:

> 
> On Feb 23, 2011, at 6:52 PM, Andrew Alston wrote:
> 
>> 
>> 
>> 
>> On 2011/02/23 8:54 PM, "Jackson Muthili" <jacksonmuthi at gmail.com> wrote:
>> 
>>> Owen,
>>> 
>>> On Tue, Feb 22, 2011 at 12:22 AM, Owen DeLong <owen at delong.com> wrote:
>>>> 
>>>> On Feb 21, 2011, at 1:12 PM, Jackson Muthili wrote:
>>>> 
>>>>> On Mon, Feb 21, 2011 at 10:51 PM, Owen DeLong <owen at delong.com> wrote:
>>>>> 
>>>>>>>> AfriNIC resources are for the AfriNIC geographical region. For each
>>>>>>>> allocation or assignment made during the Exhaustion Phase, no more than
>>>>>>>> 10% of these resources may be used outside of the AfriNIC region, and
>>>>>>>> any use outside the AfriNIC region shall be solely in support of
>>>>>>>> connectivity back to the AfriNIC region.
>>>>>>> 
>>>>>>> How is this measured? What counts as 'outside'?
>>>>>>> 
>>>>>> AfriNIC has a clearly defined geographical service region. If an address
>>>>>> is
>>>>>> assigned to a device physically outside of that defined region, then, the
>>>>>> address is being used outside of the region. This does not seem like
>>>>>> rocket science to me.
>>>>> 
>>>>> What happens to african ISPs having customers outside the service
>>>>> region, if those customers can consume more than 10% of the ISP
>>>>> allocation?
>>>> 
>>>> They probably should seek addresses for those customers from an
>>>> out-of-region RIR? This is permitted by all of the RIRs, I believe.
>>> 
>>> Only when the ISP has legal presence in that RIR region of service.
>>> Dont all RIRs restrict resource provision to their service region?
>>> 
>> 
>> Errr, sorry, but I need to point out something at this point.  This is the
>> soft landing policy, by the time this policy kicks in, they will be UNABLE
>> to seek resources out of region.  Currently AfriNIC's IP burn rate is such
>> that by the time that this policy kicks in, everyone else will have depleted
>> and only be offering v6.
>> 
>> Therefore, anyone wanting space for global expansion will HAVE to get it
>> from AfriNIC and announce it off continent.  That or be told that they can't
>> have any and can't expand.
>> 
>> Further more, irrespective of how big said company was before and how much
>> space they had pre this policy kicking in, under current wording of said
>> policy, they cannot use more than 10% of *THAT* allocation off continent.
>> Are we now saying that said company must renumber loads of things to move
>> old allocations that weren't allocated under this policy off continent so
>> that they can use the new space within the geographic region?  Because under
>> this policy wording, that would be allowed as well, though it does kind of
>> defeat the point of the policy.
>> 
>> I have HUGE issues with us saying that when a genuine African company has IP
>> space from AfriNIC they should be restricted as to where they use it, when
>> they cannot get space elsewhere.  We live in a global world, business is
>> global, communications are global, are we as Africans going to continue to
>> try and hide in our corner of the world while the rest of the world moves
>> on, and deny ourselves the ability to grow into the global economy?  Because
>> THAT I believe is the net effect of this.
>> 
>> Andrew
> 
> If you can come up with a good definition for policy of a genuine African
> company (and not a shell company with an office somewhere in
> Africa for the purpose of exporting addresses) that would prevent
> the exploitation of resources out of region while complying with the
> letter of the policy (if not the intent), that I would welcome that change.
> 
> Otherwise, I think that the likelihood of this being an issue in IPv4
> compared to the much greater harm that comes without this
> protection makes the 10% provision necessary.
> 

Owen, considering that this provision is ENTIRELY unenforceable, cannot be
policed and creates the danger of limited global expansion, I fail to see
what dangers the removal of this clause creates.  In the same way as you
challenge me to provide a definition of an African company, which I will
fully admit is not something I can do without much forethought, I challenge
you to show me a way that we can enforce this provision and give it any
meaning.  

A.) How exactly are you going to prove where the space is in use (Closest
exchange point is meaningless, and I can give you concrete demonstration of
why if you wish, latency is meaningless, and again, I can give you concrete
examples of why if you wish, RDNS entries on infrastructure is useless,
since you can set those to anything you wish, transit providers are
meaningless in the world of long haul/long wire transport circuits), so,
show me how you plan to actually enforce this.

B.) Without RPKI in place (and that is something I will be fighting against
with every breath in my body considering the hugely inherent dangers of RPKI
implementation), how can we actually STOP a company announcing the space
even if we DO come up with a way to prove they are using it off the African
continent?  Sue them?  Does AfriNIC have that kinda resource?  Do we want
AfriNIC to become a police force?

C.) As I pointed out, the clause restricts ISPs from using more than 10% of
the space allocated UNDER THIS POLICY outside of Africa, pray tell what is
stopping people from renumbering their African resources with the new space
and then taking a previous allocation and using that overseas, in which case
this clause is effectively NULL AND VOID.  I would also object VERY strongly
to any policy modification that imposed such limitations retroactively on
previously allocated space.

So, considering points A,B and C can you please either answer those or give
me a demonstration of what danger scrapping this clause creates rather than
some vague hypothetical statement.

Thanks

Andrew




More information about the RPD mailing list