[Community-Discuss] IPv4 depletion in AFRINIC will speed up IPv6 adoption - myth or fact?

ALAIN AINA aalain at trstech.net
Tue Nov 1 15:31:41 UTC 2016


Hello,

> On Oct 29, 2016, at 7:18 PM, Andrew Alston <Andrew.Alston at liquidtelecom.com> wrote:
> 
>  
> Ø  Yes. the usual story. You only know. Others are either clueless or naive..
>  
> Not at all, I’m sure there are plenty of people who may know better than me.  Unfortunately, as of yet, none of them have bothered to provide realistic ways of doing this that contain *detailed* proposals of how this would be accomplished and what the end results are.

There are plenty of people here who know far more than me and you , but resolve not to speak as you have made this a low floor, repetitive and non  productive discussions.

The policy proposal was introduced  on the 18 May 2016, and we have had  these discussions. RPD  and the  AFRINIC-24 policy archives are available.

Now  that you have asked again, see below...

>  
> See Alain, the difference here, I ask for hard facts and data – and when I’m asked for such I provide it – but I will not accept vague positions and unsubstantiated nonsense as the grounds for implementing a policy.
>  
> a.)    No one has yet proposed how these audits are meant to be realistically done beyond looking at the routing tables

Policy proposals do not  dictate implementation, but describe principles to action.

The policy  proposal aims to seek compliance to RSA which all members sign before applying for the number ressources. Section 4 of the RSA is very clear on parties responsibilities. http://www.afrinic.net/en/services/rs/rsa <http://www.afrinic.net/en/services/rs/rsa>

The policy proposal  says :
===

3.4 In case of non-compliance and if evidence has been established in accordance with the non-exhaustive list below:

Unjustified lack of visibility of the resource on the global routing table.
Breach of AFRINIC policies.
Breach of the provisions of the registration service agreement or other legal agreements between the organization holding the resource and AFRINIC.
Evidence that an organisation is no more operating and its blocks have not been transferred.
Unauthorized transfers of resources.
===

Looking at the global  Internet routing table at a given time is an option. Visibility or not in the global Internet Routing Table gives an indication of how to reach the destination, but does not tell about utilisation. A prefix can easily be seen in the Global Internet Table without  being used. 
 Utilisation in compliance with RSA and policies is what is sought here.  What AFRINIC will be trying to establish is utilisation based on justified  needs  and compliance with RSA. In doing so, Members are  bound to collaborate with AFRINIC as said in section 4.(4) below.

===

(b) Cooperation:

(i) An applicant receiving service under an agreement is at all times bound to provide to AFRINIC such information, assistance and cooperation as may be reasonably required by the latter in the provision of the service.

(ii) Such request for information may also be made where AFRINIC is investigating (reviewing) the applicant's utilisation of the numbering resources already assigned to it.

(iii) Failure by the applicant, to comply with a request made at above may:

entail revocation or withholding of the service supplied by AFRINIC;
be taken into account by AFRINIC in its evaluation for further and future assignment or allocation of numbering resources;
lead to the closure of an LIR and termination of the agreement by AFRINIC.

===

Investigated members to provide  information and data to convince AFRINIC which may not need to do  much.

“Say what you do, do what you say and prove it."


> b.)    No one has proposed where the resources to do these audits are meant to come from
> 

AFRINIC as RIR is already committed to do this review as prescribed in the RSA. This proposal is just  guidelines on how to implement it.  But if there is a need for extra ressources, it is up to  AFRINIC staff to say so. The PDP has provision for staff analysis on Policy proposal. Shall co-chairs request one ?


> c.)    No one has addressed the MASSIVE potential for abuse of this policy
> 

I remembered  the discussions on possible abuse on  the “reported” class of the policy proposal.

===
3.3.3 Reported: Here, members are reviewed either because:
They have requested the review themselves or
there has been a community complaint made against them that warrants investigation.
===

This has been addressed as we all trust AFRINIC to do the right job and as a community, we stand to revive policies and implementations in case of known abuses.

People have been complaining  about flaws in current policies, practices which have been abused by some members.

> d.)    No one has addressed the fact that if an audit is needed – then the original documentation is in question – and at that point you are by the very nature of requesting the audit saying the hostmasters didn’t do their jobs when verifying the application in the first place – and if you want to make implications like that – you need evidence.
> 

The application approved by Hostmasters at the first place serves as basis to all reviews. Questioning  applications approved by Hostmasters is a different matter.

>  
> I am sick and tired of vague statements, vague insinuations, vague claims that everyone is stealing the space and taking it elsewhere,

Ah bon ? I have not heard that.  But in case this exist, I would expect this policy proposal to help clear the point.

> vague claims that presentations that report on one thing some how are actually reporting on other issues they don’t ever reference. 

There are data in there, plus some conclusions. Nothing prevents further analysis and readings of the data.

—Alain

>  
> Come with real data – real facts – real figures – and then let’s have this discussion.
>  
> Andrew
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/community-discuss/attachments/20161101/1240e395/attachment.html>


More information about the Community-Discuss mailing list