[rpd] Opposing the last call made on the review policy

Sat Dec 1 11:47:27 UTC 2018

Thanks for the clarification Andrew.

On Sat, 1 Dec 2018, 11:54 AM Andrew Alston <Andrew.Alston at liquidtelecom.com
wrote:

> Tim,
>
>
>
> Let me quote from the MSA:
>
>
>
> Section 2.
>
> *(c) clearly indicate the service(s) for which the application is being
> made;*
>
>
>
> Section  4.
>
> *(c) Applicant’s use of the service The Applicant hereby irrevocably: *
>
> *(i) Commits itself to using the services solely for the purpose for which
> it was requested*
>
>
>
>
>
> Now – the argument could be made that function Section 4.a there is the
> possibility of changing things – however – let us look at what that says:
>
> (a) Where a member, receiving service under an existing agreement applies
> for a change or a variation of the type of such service which AFRINIC has
> been supplying to it, evaluation of such a “change request” will be
> effected in terms of the provisions of clause (2) of the present agreement.
>
>
>
>
>
> The service supplied is IP addresses – there is no change in the actual
> service supplied should the motivation for the service change – hence –
> this actually does not cover this situation.
>
>
>
> Further, section 4.(c).(iv) again makes reference to changes:
>
>
>
> *(3) update any data submitted to AFRINIC in the context of: a. an
> application for a Registration Service Agreement or b. the renewal of any
> Registration Service Agreement*
>
>
>
> The change of reason for application for IP space does not constitute a
> renewal of the RSA – the RSA does not expire so again – this is not
> applicable.
>
>
>
> Furthermore section 6.(d).(iii) states:
>
>
>
> *(iii) that it is bestowed with an exclusive right of use of those number
> resources within the ambit of the “need” which it has justified in its
> application and for no other purpose during the currency of the present
> agreement;*
>
>
>
> Then, we go to the policies – since the RSA binds its members to the
> policies:
>
>
>
> In order to meet an application requirement – section 5.2.3 of the
> consolidated policy manual reads:
>
>
>
> *In order to properly evaluate requests, an RIR must carefully examine all
> relevant documentation relating to the networks in question. Such
> documentation may include network engineering plans, sub-netting plans,
> descriptions of network topology, and descriptions of network routing
> plans. All documentation should conform to a consistent standard and any
> estimates and predictions that are documented must be realistic and
> justifiable.*
>
>
>
> It stands to reason that any audit would then need to verify that the
> conditions of 5.2.3 are met – and without the documentation that is
> impossible to do.
>
>
>
> What you are effectively saying is that anyone who’s documentation AfriNIC
> has lost – would in effect be applying for their space all over again – and
> it would be the equivelant of a new application – that is totally
> unrealistic and untenable – because for that to be done in an equitable
> manner – AfriNIC would have to do the same for **EVERY SINGLE
> ORGANISATION** who’s documentation they are missing – are we really
> saying you are going to force half the continent to reapply for their
> space?
>
Like I said before, unless we have the stats and exactly what we are
dealing with, it is wrong to assume 'half the continent' unless of course
you know more than what the staff of AFRINIC knows at the moment. I wait
patiently for the clarification from the CEO.

>
>
> I also refer to section 5.5.1.11:
>
>
>
> *5.5.1.11 Validity of an assignment*
>
> *Assignments remain valid as long as the original criteria on which the
> assignment was based are still in place and the assignment is registered in
> the AFRINIC database. An assignment is therefore invalid if it is not
> registered in the database and if the purpose for which it was registered
> has changed or no longer holds.*
>
>
>
> That – by policy – says if the reason for application has changed the
> assignment is invalid – and its crystal clear – and if you cannot
> adjudicate on the reason for assignment because the documentation is
> missing – well – good luck with that one if you want to strip half the
> continent of its IP space – there is this little thing called “in the
> public interest” – and if anyone thinks that this would meet that criteria
> – well – just no
>
>
>
> Andrew
>
>
>
>
>
> *From: *Timothy Ola Akinfenwa <akin.akinfenwa at uniosun.edu.ng>
> *Date: *Saturday, 1 December 2018 at 13:36
> *To: *Andrew Alston <Andrew.Alston at liquidtelecom.com>
> *Cc: *Mark Elkins <mje at posix.co.za>, rpd List <rpd at afrinic.net>
> *Subject: *Re: [rpd] Opposing the last call made on the review policy
>
>
>
> Andrew,
>
> On Sat, 1 Dec 2018, 11:10 AM Andrew Alston <
> Andrew.Alston at liquidtelecom.com wrote:
>
> Comments in line –
>
>
>
> *In the likely event that your claim is correct, moving forward, I will
> like to ask if it will be impossible for the organisation under review to
> provide all necessary documents (including the lost, the archived, the
> forsaken body of emails) to justify the manner of usage of their allocated
> resources? The policy proposal gave a timeline for the entity under review
> to provide documentation (both lost and retrievable, I suppose) to justify
> and assist staff investigation. This should be sufficient IMHO! *
>
>
>
> *I believe an error can be corrected at the point of discovery. This is
> applicable to any organisation. That we should wait till we resolve issues
> of lost and long gone documentations before proceeding with the review of
> allocated resources (which the RSA already stated clearly) is
> impracticable!*
>
>
>
> I strongly disagree with this – because it opens the door to an
> organization being able at will to change the justification for space that
> is not afforded to other organizations.
>
>
>
> As an example – if an entity applied for space for purpose X and a review
> is done, and documentation is available, and they are found to NOT be using
> the space for purpose X, there is nothing in the policy that allows for a
> revised usage state – that simply is not there under the current policy as
> proposed.
>
> Is there anything like a *revised usage state* in the RSA that allows an
> entity to come forward at will or upon invitation to revise the purpose for
> which a previously allocated resource(s) was based? I'll like be clear on
> this.
>
> However, if an entity applied for space for purpose Y and the
> documentation is NOT there, they are then free to modify their motivation
> and justification as they wish and claim it as the original justification –
> this is drastically prejudicial to those who’s documentation AfriNIC still
> has and is not uniform of equitable.
>
> To be honest, this is not impossible. However, as I stated earlier, the
> CEO or anyone responsible for this may have to clarify this situation to
> the community and the extent of damage, just in case this assertion is
> true. We may be able to proffer a reasonable solution, moving forward.
>
>
>
> The way to fix this would be a modification of policy to cater for this
> situation – which should have happened under staff review had they brought
> this to the attention of the community.  This was not done – and since a
> policy that is modified has to go back to the floor for ratification – this
> policy cannot go through in its current form – because it is prejudicial
> and I would argue anyone reviewed under this policy would have grounds to
> challenge the review on the lack of ability to uniformly apply the policy
> and the methods of review, thereby invalidating the entire policy.
>
> While not being pre-emptive of the appeal process, I think it is the only
> way forward to challenge the rough consensus already declared by the
> Co-chairs.
>
>
>
> Andrew
>
>
>
>
>
> Andrew
>
>
>
>
>
> *From: *Timothy Ola Akinfenwa <akin.akinfenwa at uniosun.edu.ng>
> *Date: *Saturday, 1 December 2018 at 11:51
> *To: *Andrew Alston <Andrew.Alston at liquidtelecom.com>
> *Cc: *Mark Elkins <mje at posix.co.za>, rpd List <rpd at afrinic.net>
> *Subject: *Re: [rpd] Opposing the last call made on the review policy
>
>
>
> Andrew,
>
> On Sat, 1 Dec 2018, 9:40 AM Andrew Alston <Andrew.Alston at liquidtelecom.com
> wrote:
>
> Timothy,
>
>
>
> AfriNIC HAS **NEVER* *publicly acknowledged the loss of a large portion
> of attachments associated with application documents.  How is it that when
> we talk about audit and staff assessment – that it does not come to light
> to the community that Afrinic does not even have a large amount of
> documentation associated with the applications that would demonstrate how
> they were applied for?
>
> This will be serious if true. I think the AFRINIC CEO should provide
> clarification to this. I will not like to be misled. Just in case this
> claim is true, has it been remedied? When too?
>
>
>
> This documentation I still maintain is critical for a fair audit that
> covers all aspects – and if you do not have said documentation for ALL
> members – to act on it against SOME members would be prejudicial.
>
> I agree with you on this, only if the above is confirmed to be correct.
>
>
>
> So to refer to staff assessment – how was THIS not brought up in staff
> assessment – and does this not put paid to the lie that the staff
> assessment in and of itself is flawed?
>
> This has to be clarified too, just only if and only if your previous
> assertion was true!
>
>
>
> Andrew
>
>
>
>
>
> *From: *Timothy Ola Akinfenwa <akin.akinfenwa at uniosun.edu.ng>
> *Date: *Saturday, 1 December 2018 at 11:23
> *To: *Mark Elkins <mje at posix.co.za>
> *Cc: *rpd List <rpd at afrinic.net>
> *Subject: *Re: [rpd] Opposing the last call made on the review policy
>
>
>
> Hello Mark,
>
> See responses in-line
>
> On Sat, 1 Dec 2018, 8:52 AM Mark Elkins <mje at posix.co.za wrote:
>
> From what Andrew is saying - the policy should never have gone to last
> call if there have been no changes. That's how the PDP process is meant to
> work. In reality - if the whole community accepted seeing a policy for the
> second time - then fair enough - but that is NOT the case here. I strongly
> oppose this policy. I have also watched the antics of the people pushing
> this policy and I think it was extremely rude and totally out of place for
> one of their party to call someone else in the room a "visitor" -
> suggesting that that other person had no rights to be present. The person
> being subjected to this treatment provided much needed input (and policies)
> to the Policy Development Process - especially regarding IPv6 - which is
> our future.
> We should have no place for Name Calling.
>
> Not speaking for the person here, but I remembered watching it remotely
> where the said person clarified his statement.
>
> I never heard an apology either.
>
> I think you should watch again, the person apologised if his statement has
> been misinterpreted and even heard applause from the room afterwards.
>
> Anyway - I believe that the PDP Co-Chairs have made a mistake and this
> Policy has not reached a positive Consensus (actually quite the opposite to
> Positive). It should not be at last call.
>
> The Policy - if used - is also extremely dangerous to the existence and
> financial well being of the Company (AFRINIC).
> It really should be withdrawn.
>
> I thought Staff Assessment was conducted. I believe this must have been
> sorted out and necessary clarification provided.
>
> On 12/1/18 9:15 AM, Andrew Alston wrote:
>
> Sorry – I need to correct something in my email below –
>
>
>
> I said there were no _*substantive*_ changes since the last rejection of
> this policy – this is inaccurate – there were **NO** - changes –
> substantive or otherwise – zero – zip – none – as per the website which
> publishes draft 6
>
>
>
> Andrew
>
>
>
>
>
> *From: *Andrew Alston <Andrew.Alston at liquidtelecom.com>
> <Andrew.Alston at liquidtelecom.com>
> *Date: *Saturday, 1 December 2018 at 09:27
> *To: *"aleruchichuku at yahoo.com" <aleruchichuku at yahoo.com>
> <aleruchichuku at yahoo.com> <aleruchichuku at yahoo.com>, Daniel Yakmut
> <yakmutd at googlemail.com> <yakmutd at googlemail.com>, Daniel Yakmut via RPD
> <rpd at afrinic.net> <rpd at afrinic.net>
> *Subject: *Re: [rpd] Opposing the last call made on the review policy
>
>
>
> Aleruchi,
>
>
>
> While I agree with everything you have said – let us also be pragmatic.
> This policy is pushed by the same crowd that walked to the microphone and
> agreed at the request of the community to drop another policy, and then
> reneged on it.  This policy has been rejected, as has the soft landing
> policy, over and over again – yet the authors do not give a damn about the
> will of the community or the good of the community.  Go and watch the
> videos of the Mauritian policy meeting – you will notice the same people
> involved in what happened there are involved in this policy as well.
>
>
>
> The authors have clearly demonstrated that they care not a whit about what
> this community wants or believes is good for it, they have demonstrated bad
> faith, and shown that the only thing they care about is shoving something
> through no matter the consequence – and the co-chairs have already shown
> that they either do not understand the concept of consensus – or simply do
> not care.  Fact is – there is precedent on co-chairs being overturned on
> appeal in another RIR – and when it happened – the person who was
> overturned – ceased to be a co-chair.  These co-chairs however are
> insistent on a path that ignores the consensus process, and seem hell bent
> on forcing a situation where they are overturned – yet again – or failing
> that forcing AfriNIC into an untenable and potentially costly process
> beyond the appeal process.
>
>
>
> Reality is – there were _*no*_ substantive changes to this policy from
> the last time it was rejected – and the objections to the policy that were
> stated back then have never been withdrawn, and by lack of changes in the
> text can be clearly demonstrated to not have been addressed – this flies in
> the very face of the definition of consensus – the co-chairs however simply
> do not care.
>
>
>
> Welcome to what our PDP process has become – the bullying of the minority
> supported by co-chairs who do not understand consensus – to push through
> agendas that have zero to do with the good of the community and more to do
> with standing your ground to prove that you can.
>
>
>
> And btw – before I’m attacked – yes – I have proposed some controversial
> policies over the years – fact is – all of them were withdrawn when the
> community wanted that.
>
>
>
> Andrew
>
>
>
> *From: *aleruchi chuku via RPD <rpd at afrinic.net> <rpd at afrinic.net>
> *Reply-To: *"aleruchichuku at yahoo.com" <aleruchichuku at yahoo.com>
> <aleruchichuku at yahoo.com> <aleruchichuku at yahoo.com>
> *Date: *Saturday, 1 December 2018 at 07:02
> *To: *Daniel Yakmut <yakmutd at googlemail.com> <yakmutd at googlemail.com>,
> Daniel Yakmut via RPD <rpd at afrinic.net> <rpd at afrinic.net>, rpd List
> <rpd at afrinic.net> <rpd at afrinic.net>
> *Subject: *Re: [rpd] Opposing the last call made on the review policy
>
>
>
> It's very sad that this policy still lingers like a nightmare after it has
> been rejected over and over again. It has consistently bred anger and
> mistrust.
>
> Please for the sake of unity, I will advice the chairs to do what is right
> by the people. DROP THIS POLICY.
>
>
>
> Cheers
>
> Aleruchi
>
> Sent from Yahoo Mail on Android
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
>
>
> On Sat, 1 Dec 2018 at 4:15 am, Daniel Yakmut via RPD
>
> <rpd at afrinic.net> <rpd at afrinic.net> wrote:
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
> _______________________________________________
>
> RPD mailing list
>
> RPD at afrinic.net
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> --
>
> Mark James ELKINS  -  Posix Systems - (South) Africa
>
> mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
>
> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo
> <https://lists.afrinic.net/mailman/listinfo/rpd>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20181201/3d6dc5bc/attachment-0001.html>