[rpd] Co-Chair Election Process

[Fernando Frediani]

Thanks for sharing your reading on it but that not 'plain English' as it 
may look like.  3.6 was written and thought for policy proposal 
procedures not for what we are doing right now. What we are doing right 
now is pure free discussion and speculation. You have your view and I 
have mine. Using 3.6 to do something else is a 'glued solution' that 
doesn't correspond to what it was thought to.

For 3.6 to be used a proposal must be presented and be under discussion 
with review and Last Call for at least 4 weeks. If it passes then fine 
to conduct the resolution of this issue under these new terms properly 
justified as 3.6 outlines.

Fernando

On 21/07/2020 00:05, Owen DeLong wrote:

>

>

>> On Jul 20, 2020, at 6:22 PM, Fernando Frediani <fhfrediani at gmail.com 

>> <mailto:fhfrediani at gmail.com>> wrote:

>>

>> Hi Owen. Sorry I don't really read the 3.6 the same way as you. 3.6 

>> in my view wasn't thought for situation like this. It's being glued 

>> for the occasion that's not the case. 3.6 is about how the proposals 

>> are conducted, reviewed and passed within this forum in a exceptional 

>> situation (pretty much where we are). All points mentioned there have 

>> to do with proposals. We are not discussing or advancing a proposal 

>> right now.

>>

>

> That’s your special interpretation. It’s not what a plain english 

> reading of the language says.

>

> 1.The PDP is in the document containing 3.6. The PDP is a process.

> 2.The co-chair election process is in the document containing 3.6. The 

> co-chair election process is a process.

> 3.3.6 says “The process outlined in this document…”.

>

>> What CAN actually be done within 3.6 is someone to properly present a 

>> proposal to amend the PDP and fix the issues we are discussing here 

>> and then have this proposal treated under 3.6 (with no less than 4 

>> weeks including the Last Call - which coincides with your point 

>> number 3 below).

>>

> I suppose that could also work, though it’s rather indirect and adds 

> (unnecessary IMHO) complexity.

>>

>> In my opinion proposal AFPUB-2019-GEN-007-DRAFT01 is ready for it, 

>> but I guess that may not reach consensus. So a much shorter proposal 

>> with just the essential we need to resolve this situation is the way 

>> to go under 3.6. Would that match with what you are trying to put ?

>>

>

> IMHO, AFPUB-2019-GEN-007-DRAFT01 is a fatally flawed proposal and I 

> would not support it as currently written.

>

> I think a much more direct proposal to clarify an expanded scope of 

> 3.6 (closer to my interpretation instead of your rather narrow 

> interpretation) would be the most likely to gain consensus, frankly. I 

> think such is unnecessary, but _IF_ you insist on the (oddly) narrow 

> interpretation of 3.6 you have put forth, then…

>

> Owen

>

>> Fernando

>>

>> On 20/07/2020 21:52, Owen DeLong wrote:

>>>

>>>

>>>> On Jul 20, 2020, at 10:00 AM, Fernando Frediani 

>>>> <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> wrote:

>>>>

>>>> On 20/07/2020 13:39, Owen DeLong wrote:

>>>>>

>>>>> <clip>

>>>>>

>>>>> This is an absurd claim. The standard (as you mention below) is a 

>>>>> “raise of hands” vote. This mechanism even in person does not 

>>>>> allow people to verify that their vote was cast correctly, nor is 

>>>>> it fully auditable (indeed, it has no audit trail and is not at 

>>>>> all audible).

>>>>>

>>>>> Placing more stringent requirements than exist on the current 

>>>>> system as an acceptance criteria for a system deployed urgently in 

>>>>> a time of crisis makes little sense to me.

>>>> You are not making the things easier given the circumstances and 

>>>> all has been been discussed here.

>>>> What is being said is analogous to raise of hand and is also a 

>>>> indisputable way to eliminate most possible fraud that have been 

>>>> pointed.

>>>

>>> It is not my goal to make things easier for you or even necessarily 

>>> easier in general.

>>>

>>> It is my goal to achieve the best possible outcome through a 

>>> mechanism that comes as close to applying the PDP rules as possible.

>>>

>>>>>> 4 - In order to either choose another Co-Chair or to extend the 

>>>>>> current one term there must be a vote with raise of hands. There 

>>>>>> is no other way out of the PDP this can be done.

>>>>>>

>>>>>

>>>>> This statement ignores CPM section 3.6:

>>>>>

>>>>>

>>>>>           3.6  Varying the Process

>>>>>

>>>>>     The process outlined in this document may vary in the case of

>>>>>     an emergency. Variance is for use when a one-time waiving of

>>>>>     some provision of this document is required.

>>>>>

>>>>>      1. The decision to vary the process is taken by a Working

>>>>>         Group Chair.

>>>>>      2. There must be an explanation about why the variance is needed.

>>>>>      3. The review period, including the Last Call, shall not be

>>>>>         less than four weeks.

>>>>>      4. If there is consensus, the policy is approved and it must

>>>>>         be presented at the next Public Policy Meeting.

>>>>>

>>>>>

>>>>> Clearly this is the kind of exceptional circumstance in which some 

>>>>> variance could be justified.

>>>> Sorry I don't see 3.6 applying to this situation on *any* of points 

>>>> mentioned. This section is about how the policies discussion, 

>>>> review, last call, etc work  1) As I understand this decision is 

>>>> not up to the Chairs to take 2)Yes, we are working on the 

>>>> explanation, but who will give it ? Normally is whoever take the 

>>>> decision. 3) Nothing to do with elections 4) Nothing to do with the 

>>>> current scenario. There is no proper policy under discussion to be 

>>>> approved, only a discussion of what to do about the next elections.

>>>

>>> It applies to all of the CPM ("The process outlined in this document 

>>> may vary…”).

>>> 1. If not the co-chairs, then who?

>>> 2. I think the explanation is well understood… “Because in person 

>>> meeting during the COVID crisis is impossible.”

>>> 3. I’m not so sure about this. Whatever election process we decide 

>>> on should be put to a final community comment

>>> period of some form. I see no reason that should be less than 4 weeks.

>>> 4. So you’re saying that the determination of how to (or whether to) 

>>> conduct co-chair elections should be made

>>> by some other method than community consensus and should not be 

>>> considered policy at least for this meeting?

>>>

>>> How does that work?

>>>

>>>

>>>>>

>>>>> I still say that a (virtual) raising of hands using the mechanisms 

>>>>> available in nearly every conferencing system capable of supporting

>>>>> this meeting has the following advantages:

>>>>> q

>>>>> 1.Only meeting attendees may vote.

>>>>> 2.Botting your meeting attendance would be reasonably difficult, 

>>>>> so it would be difficult for a person to stuff the ballot box.

>>>>> 3.It does meet the literal requirements of the existing PDP.

>>>>> 4.If we place reasonable bounds on meeting registration, we can 

>>>>> avoid the so-called “sleeper cell” effect that some have

>>>>> put forth as a concern. (Personally, I think this is less likely 

>>>>> in a virtual meeting anyway).

>>>>> 5.If we place reasonable bounds on meeting registration, we also 

>>>>> manage to prevent (2) from being a concern.

>>>>> 6.By “reasonable bounds”, I mean pick a date certain in the past 

>>>>> by which one must have been subscribed to RPD.

>>>>> Each email subscribed to RPD is entitled to one corresponding 

>>>>> meeting registration if they choose to. No subscribed

>>>>> email, no registration for the meeting.

>>>> I quiet like this idea, and that is exactly which is under 

>>>> discussion in one of the policies that should advance, but this is 

>>>> not backed in any part of PDP as far as I know as the moment. Who 

>>>> will determine what date is this ?

>>>

>>> This would most certainly be a variation of the PDP to meet the 

>>> emergency as it exists which would be permitted under 3.6, so, yes,

>>> my argument here depends on my argument above which you have claimed 

>>> you are not buying. However, hopefully with my expansions on

>>> the topic above, I can perhaps convince you to change your mind and 

>>> recognize that without something like that, we literally box

>>> ourselves into a situation with no way forward until such time as we 

>>> can arrange an in-person meeting. Personally, I think that’s

>>> far from the best outcome.

>>>

>>>>> 7.My suggestions for the date certain would be the first day of 

>>>>> the originally scheduled in person AIS 2020 (May 31) or

>>>>> the originally scheduled first day of the public policy meeting 

>>>>> (June 8 IIRC).

>>>>

>>>> This would make sense if there was basis for it, but currently 

>>>> there is AFAIK.

>>>>

>>> The basis for it is 3.6. Read the CPM carefully read 3.6. It’s not 

>>> rocket science. The CPM describes all of the policies, the PDP, and 

>>> the co-chair election process within the one document. Section 3.6 

>>> provides for variance of the process[sic] should be processes within

>>> the document. That includes the co-chair election process unless you 

>>> can show me why it does not.

>>>

>>> Owen

>>>

>>>> Fernando

>>>>

>>>>>

>>>>> If anyone has a reason they don’t think this is viable, please 

>>>>> express it. So far, I’ve seen lots of calls for other solutions, 

>>>>> but this

>>>>> seems to be the approach with the fewest drawbacks and which can 

>>>>> easily be implemented in time.

>>>>>

>>>>> Owen

>>>>>

>>>>>>

>>>>>> Regards

>>>>>> Fernando

>>>>>>

>>>>>> On 20/07/2020 03:06, Daniel Yakmut wrote:

>>>>>>> Dear All,

>>>>>>>

>>>>>>> We arrive at the airport and I will be turning the simple matter 

>>>>>>> placed on the table into a circus. The simple matter was:

>>>>>>>

>>>>>>> 1. We will have AIS 2020 online and in September.

>>>>>>> 2. A Co-chair's  tenure has already ended. So an electronic 

>>>>>>> election is being proposed as part of the AIS 2020 Agenda. The 

>>>>>>> question is, is this possible?

>>>>>>> 3. It is a fact that the Co-chair is currently serving within an 

>>>>>>> extended period.

>>>>>>> 4. We now agree that the introduction of e-voting is inevitable, 

>>>>>>> as demonstrated by the pandemic.

>>>>>>>

>>>>>>> However it is clear that

>>>>>>> 1. We are going to have an online meeting , as nobody has 

>>>>>>> disagreed to that.

>>>>>>> 2. There is a strong advocacy, for a process to include e-voting 

>>>>>>> in the Region, but the timing is short. Therefore we need to 

>>>>>>> commence the plan of creating an enabling atmosphere to 

>>>>>>> integrate e-voting.

>>>>>>> 3. We need to ratify the extended period for a co-chair 

>>>>>>> tentatively for 12months. Which he has spent a month or so already.

>>>>>>> 4. Ensure we have an acceptable e-voting system ready for the 

>>>>>>> next date of election.

>>>>>>> 5. Let agreed clearly on this simple issue and prepare for the 

>>>>>>> coming meeting.

>>>>>>>

>>>>>>> Simply

>>>>>>> Daniel

>>>>>>>

>>>>>>> On Jul 19, 2020 11:20 PM, "Fernando Frediani" 

>>>>>>> <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> wrote:

>>>>>>>

>>>>>>>     I have read this message and several questions come to mind

>>>>>>>     as for example:

>>>>>>>

>>>>>>>     - What basis was used to say "it was overwhelmingly" rejected ?

>>>>>>>

>>>>>>>     - Who actuallty represents the "current" community to state

>>>>>>>     it was "totally rejected" ?

>>>>>>>

>>>>>>>     - Whats basis was used to say that it would not work in the

>>>>>>>     region if that works in several other places and RIRs

>>>>>>>     including, with auditable systems ?

>>>>>>>

>>>>>>>     - Whats basis is used to say rhe community that voted for

>>>>>>>     the current Co-Chair in Kampla has the same confidence in

>>>>>>>     him and that he would win ? It seems more a personal wish

>>>>>>>     than anything based on fact or logic.

>>>>>>>

>>>>>>>     - Even in order to extend the current Co-Chair term the PDP

>>>>>>>     MUST be followed and there are no other ways written there

>>>>>>>     other than another vote. Otherwise how can this be done ?

>>>>>>>

>>>>>>>     Fernando

>>>>>>>

>>>>>>>

>>>>>>>     On Sun, 19 Jul 2020, 18:08 Emem William,

>>>>>>>     <dwizard65 at gmail.com <mailto:dwizard65 at gmail.com>> wrote:

>>>>>>>

>>>>>>>         Dear All,

>>>>>>>

>>>>>>>         I can recollect that a similar proposal was proposed as

>>>>>>>         a policy and it was overwhelmingly rejected in Angola.

>>>>>>>         The current community totally rejected the policy no one

>>>>>>>         except the authors supported the idea because we know it

>>>>>>>         can't work in this region. Using online voting now would

>>>>>>>         be like passing the policy using the backdoor. Am sure

>>>>>>>         Jordie would like this idea and hence his enthusiasm.

>>>>>>>         However my candid opinion is that we can't do this. The

>>>>>>>         most appropriate way forward is to allow the Co chair

>>>>>>>         who has been doing a fantastic job to continue for

>>>>>>>         another 12 months or till the next face to face meeting.

>>>>>>>         The community that voted him in Kampala still have

>>>>>>>         confidence in him. In any case even with an online

>>>>>>>         election he would still likely win but I don't want

>>>>>>>         polices to be passed through the back door. Therefore I

>>>>>>>         think the most appropriate way for this has been

>>>>>>>         suggested as an extension for the co-chair who's seat

>>>>>>>         would have been contested.

>>>>>>>

>>>>>>>         Cheers.

>>>>>>>

>>>>>>>         Emem E. William

>>>>>>>

>>>>>>>         _______________________________________________

>>>>>>>         RPD mailing list

>>>>>>>         RPD at afrinic.net <mailto:RPD at afrinic.net>

>>>>>>>         https://lists.afrinic.net/mailman/listinfo/rpd

>>>>>>>         <https://lists.afrinic.net/mailman/listinfo/rpd>

>>>>>>>

>>>>>>>

>>>>>>>     _______________________________________________

>>>>>>>     RPD mailing list

>>>>>>>     RPD at afrinic.net <mailto:RPD at afrinic.net>

>>>>>>>     https://lists.afrinic.net/mailman/listinfo/rpd

>>>>>>>     <https://lists.afrinic.net/mailman/listinfo/rpd>

>>>>>>>

>>>>>> _______________________________________________

>>>>>> RPD mailing list

>>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>

>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd

>>>>>

>>>> _______________________________________________

>>>> RPD mailing list

>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>

>>>> https://lists.afrinic.net/mailman/listinfo/rpd

>>>

>> _______________________________________________

>> RPD mailing list

>> RPD at afrinic.net <mailto:RPD at afrinic.net>

>> https://lists.afrinic.net/mailman/listinfo/rpd

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200721/aa6ba0e0/attachment-0001.html>