2016-11-01 16:39 GMT+00:00 Andrew Alston <[email protected]>:
> Arnaud, > > > > Let me be very clear – > > > > I never expressed support for this policy – I asked a question. > > > > I am COMPLETELY opposed to this policy, and will be until such time as the > policy explicitly states that in the event of a complaint against a member, > the member is informed when he is audited who complained and the grounds > stated for the complaint. That is in line with internationally accepted > practice that the accused may have the right to confront his accuser, and > protects against malicious accusations for the sake of causing on going > work for an organisation. > > > > It opens the door for legal action against an accuser by the accused, if > the accused feels the accuser is lodging complaints that are malicious and > unsubstantiated in nature, and it means that those who are complaining and > demanding audits are doing so **backed by evidence** rather than because > they feel they can. > > > > I also argue that any person who issues a complaint should be willing to > subject themselves to automatic audit, which again, will cut down on > unfounded complaints that are not backed by evidence. > > > > In addition to this, complaints should be submitted by **members** alone, > they are the true stake holders, and I will oppose any policy that allows a > random member of the community to submit arbitrary complaints without > proof, evidence or proper substantiation. > > > Andrew, The relationship between the RIR and its members is based on trust. I feel you miss the intent of this proposal and imagine too many negative things. A network truly using resources should not care. I also feel you confuse role of policy and Afrinic staff who have responsibility to propose a process in accordance with the RSA. > Further to this, 3.4 makes reference to unauthorised transfers. I can > issue with auditing against something that is unauthorised when there is no > process to authorise it. That needs re-wording until such time as there is > a transfer policy. I also take issue with 3.4 that it is declared as a > non-exhaustive list. That is an open door for abuse, define the reasons > for audit and stick to them. > > > > I also take **HUGE** issue with 3.6 – if you want 3.6 and you want to > publish the names of companies that have been audited, firstly, you have to > publish the names as well of the requesting party, and secondly, that would > be a direct violation of the confidentiality agreements agreed to in the > RSA which you yourself refer to in the policy. > > > > Those are my thoughts – but until those issues are rectified – I do not > support this policy, nor do any of the 15 organisations which I represent > directly support this policy. > Oooh! I am not aware that we can have proxy for PDP discussions too. > Once those issues are rectified, I will **consider** support for the > policy, but the above points are deal breakers for me – after that, > consideration can be given. > --Arnaud > > > Andrew > > > > > > > > *From:* Arnaud AMELINA [mailto:[email protected]] > *Sent:* 01 November 2016 19:10 > *To:* ALAIN AINA <[email protected]> > *Cc:* General Discussions of AFRINIC <[email protected]> > *Subject:* Re: [Community-Discuss] IPv4 depletion in AFRINIC will speed > up IPv6 adoption - myth or fact? > > > > My Contribution through the lines of this message > > > > 2016-11-01 15:31 GMT+00:00 ALAIN AINA <[email protected]>: > > Hello, > > > > On Oct 29, 2016, at 7:18 PM, Andrew Alston <Andrew.Alston@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. > > > +1 @Alain > > Yes Andrew, we had good discussions and a new version of the proposal > which incorporated the changes was posted Tuesday, 9 August 2016, the > link below : > > http://www.afrinic.net/en/community/policy-development/ > policy-proposals/1827-internet-number-resources-review-by-afrinic > > And I understood trough your e-mail posted on 14 October 2016, which is > cuts below, you finally express support to this Policy proposal. > > ==== > > "Just a question about the audit policy…. > > Is it agreed that if we have such a policy, we should also audit the v6 > assignments people are holding that should be announced under the needs > based policy rules? > > Thanks" > > === > > regards > > > > > 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 > > > > 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: > > 1. entail revocation or withholding of the service supplied by AFRINIC; > 2. be taken into account by AFRINIC in its evaluation for further and > future assignment or allocation of numbering resources; > 3. 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: > > 1. They have requested the review themselves or > 2. 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 > > > > > > > _______________________________________________ > Community-Discuss mailing list > [email protected] > https://lists.afrinic.net/mailman/listinfo/community-discuss > > >
_______________________________________________ Community-Discuss mailing list [email protected] https://lists.afrinic.net/mailman/listinfo/community-discuss
