[rpd] inputs on AFPUB-2017-GEN-002-DRAFT-04 - Policy Development Process Bis

[Komi Elitcha]

Good morning from Africa, Jordi

Please read comments inline.


On 17/05/2019 18:06, JORDI PALET MARTINEZ via RPD wrote:
> Hi all,
>
> I've sent my raw notes about this policy proposal on 29th November 2018.
>
> I've looked around for email exchanged on this, and just to be safe, re-read the policy proposal and tried to re-assess my comments, so in some cases I've done some editorial changes, but basically everything remains the same.

It is bizarre that you missed co-authors mail sent on February 18, 2019 [1]

>
> My main point is still that even if this "transplantation" of the RIPE process (which again, in my opinion is one of the best PDPs), to AFRINIC, is increasing the complexity, instead of facilitating the process which is one of the reasons for the lack of participation, and adding some mistakes, with break it.

Are you saying the current PDP is so complex and causing lack of 
participation ? if yes, can you prove your statement ? Some of us 
believe that, this light PDP adopted in 2011 has shown its limits and 
leading us to the chaotic process which is chasing people away. You seem 
to miss important aspects of problems this community is addressing with 
the update of the PDP. I therefore wonder if the rest of your reasoning 
below is relevant.

>
> Here is what I believe is still not resolved:
>
> 1) Definition of rough consensus is incomplete and erroneous. The participants may be newcomers, they need to have a place to read a complete description as part of the PDP.

Can you clarify this point ?

>
> 2) The distinction among minor and major objections doesn’t make sense if you understand correctly the definition of rough consensus. This adds unnecessary complexity to the process.

Can you define complexity in this context ? Can you also define what you 
mean by “critical technical objections” in your definition of Consensus ?

See https://afrinic.net/fr/library/policies/2535-simple-update-of-the-pdp

How and when do you admit an objection as “technical” and how do you 
définie the severity “critical”? Rough consensus is well defined in 
rfc7282. Section 3.4.3 of the proposal describes techniques and 
mechanisms to reach rough consensus. Minor and major objections are 
classifications of objections to lead discussions to closure and ease 
consensus evaluation .

>
> 3) The consensus is determined only in the meeting (there is no timing for the discussion in the list) and consequently there is not a way to determine consensus from the list.

Each phase has its timeframe and cochairs make decision from Mailing 
list discussions to move proposal forward. Only proposals which pass 
discussion phase and review phase are presented at the PPM to seek 
consensus and activation of the concluding phase. We have agreed to give 
cochairs 2 weeks after the meeting to declare consensus, taking into 
consideration other factors including earlier discussions on mailing 
list. ( section 3.4.3) Section 3.7.1 of varying process allow cases 
where consensus is only determined from mailing list discussions.

>
> 4) Contradictory, consensus is not unanimity, even if not everyone consents to the decision of the group, consensus may be declared.

Contradictory??? Here is what section 3.4.3 says: “Consensus is achieved 
when everyone consents to the decision of the group. The decision may 
not be everyone’s first preference, but is acceptable to all participants.”

>
> 5) Let the chairs to decide. Providing so much details to them in the PDP means they can’t “move” on their own. Community elected them, community need to trust them. If they make a mistake in a decision, there is a last call and there is an appeal process.

Which details? The proposal is very clear on Co-chairs role and 
responsibilities in deciding about consensus. The approach to consensus 
is critical and needed

>
> 6) Phases stated are complex and unnecessary. Looks like trying to copy the RIPE PDP but with broken things. Will difficult the community participation.

It is obvious and you can see it, the proposal is not just a copy of 
RIPE PDP. If the proposed lifecycle of the policy proposal follows RIPE 
model, you can see clearly that the proposal has more provisions, taken 
from other PDPs and IETF processes. Copying part of the “best PDP” is a 
bad thing to do according to you. You seem to insinuate that this 
community is not mature enough to adhere to this kind of PDP. If there 
are some broken things, let us fix them.

>
> 7) The PDP can’t avoid having competing proposals, it is good for the process and the community to investigate several choices. It is a way for an author or a group of them to block the community progress. If I've an idea and send a proposal and the community don't like it but I'm not improving the text along the discussions, a possible way out is an alternative proposal.

Competing proposals have not brought constructive outcomes for our 
community and we all concur to that. To address the problem you raised 
above, section 3.5.1.1 has the following provision “Once adopted by the 
working group, the initiator(s) grant(s) all rights to the working group 
and the proposal becomes a community document.”

So if initiators refuse to improve a proposal as agreed by the working 
group, the decision of the future of the proposal is left to the Working 
group.

>
> 8) The WG should not decide against a policy proposal if is in scope of the PDP (so adoption phase doesn’t apply).

Adoption phase is meant to ensure a proposal falls within the scope of 
the PDP and is solving a real problem. So Adoption phase applies and 
avoid pushing discussions on solutions while there is no consensus on 
problem statement .

>
> 9) End of discussion phase brings subjective documentation of the process, biasing the community.

Can you elaborate ?

>
> 10) Impact analysis should include “more”, but just objective inputs, and not bias the community.

more than the followings ?

• AFRINIC Ltd’s understanding of the proposed policy

• Impact on the registry and Internet Number Resources

• Impact on AFRINIC Ltd’s operations/services

• Legal impact We trust staff to be objective in their analysis and 
community has the right to question and discuss the staff analysis

>
> 11) What happens if the timing with the review phase and the next meeting doesn’t match?

As we all follow the timing of the current PDP, instigators of proposal 
and the community are supposed to adhere and follow the new PDP with its 
timing

>
> 12) In the Concluding phase, it is not clear why a proposal should go back to either the discussion or the review phase.

The decision is left to co-chairs as it depends on the severity of 
issues brought during the concluding phase which nullify the consensus 
obtained after the review phase and the PPM.

>
> 13) Implementation waiver from who? The implementation timing is up to the staff and should be informed in the impact analysis.

Implementation timing is up to staff, but we set some timeframe to avoid 
abuse. section 3.8 says “The implementation date should be less than six 
months after ratification of the proposal by the board unless a waiver 
is requested.”

>
> 14) In the RIPE PDP we made last September a change, as there was a mistake in the process, following a policy proposal that I’ve authored, regarding the non-consensus after the review phase. I think you missed that point …

can you elaborate on the change ?

>
> 15) There is no point in asking for 3 individuals for an appeal. If a single community member wants to appeal a PDP decision and can't, I'm convinced he has the right to go to courts, because it is not inclusive.

Actually the proposal is requesting that an appeal be filed if only 
supported by 3 persons who participated in the discussions. A single 
community member appealing against a PDP decision and can’t obtain the 
support of 2 or 3 people who participated in the discussions ? so we 
allow anyone to game the PDP by filing fanciful appeals?

>
> Regards,
> Jordi
>   

Hope it helps.

[1] https://lists.afrinic.net/pipermail/rpd/2019/008981.html


Komi Elitcha on behalf of co-authors
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd

-- 
KE
https://www.linkedin.com/in/komi-elitcha/

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