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

[rpd] RPD Digest, Vol 166, Issue 78

Paclab ezekielj20 at gmail.com
Tue Jul 21 14:19:37 UTC 2020


I forsaw this happening, that's why I was insisting on the cancellation on
online meeting till the pandemic is over

On Tue, Jul 21, 2020 at 6:59 AM <rpd-request at afrinic.net> wrote:


> Send RPD mailing list submissions to

> rpd at afrinic.net

>

> To subscribe or unsubscribe via the World Wide Web, visit

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

> or, via email, send a message with subject or body 'help' to

> rpd-request at afrinic.net

>

> You can reach the person managing the list at

> rpd-owner at afrinic.net

>

> When replying, please edit your Subject line so it is more specific

> than "Re: Contents of RPD digest..."

>

>

> Today's Topics:

>

> 1. Re: Co-Chair Election Process (Fernando Frediani)

>

>

> ----------------------------------------------------------------------

>

> Message: 1

> Date: Tue, 21 Jul 2020 09:58:31 -0300

> From: Fernando Frediani <fhfrediani at gmail.com>

> To: "rpd >> AfriNIC Resource Policy" <rpd at afrinic.net>

> Subject: Re: [rpd] Co-Chair Election Process

> Message-ID: <2606ca05-56e7-38d3-7168-819f7db79b09 at gmail.com>

> Content-Type: text/plain; charset="utf-8"; Format="flowed"

>

> On 21/07/2020 02:06, Owen DeLong wrote:

> > Yes, but that proposal could be to vary the chair election process

> > just as much as to vary anything else in the document.

>

> Yes, as long it is conducted under a policy proposal discussion

> following 3.6 no problem at all.

>

> Now the main problem I guess is to reach consensus on something as many

> people seem too afraid of anything. So why I suggested something

> strictly simple that resolves the current scenario, even temporarily

> until we can have a proper proposal discussed later that resolves it

> long term.

>

> However some people keep suggesting to extend the Co-Chair term without

> willing to go through a simple show of hands in a remote event as the

> PDP says. So how we suppose to do this? Regardless the type of job the

> person is doing there is not other way to extend his term other than the

> process outlined in the PDP.

>

> I don't see any other ways out of it.

>

> Fernando

>

> >

> > Owen

> >

> >> 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

> >>>

> >> _______________________________________________

> >> 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/5d88410b/attachment.html

> >

>

> ------------------------------

>

> Subject: Digest Footer

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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

>

>

> ------------------------------

>

> End of RPD Digest, Vol 166, Issue 78

> ************************************

>

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


More information about the RPD mailing list