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

Mon May 20 11:03:29 UTC 2019

Hi Komi, all,

El 20/5/19 9:29, "Komi Elitcha" <kmw.elitcha at gmail.com> escribió:

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] 

Just responded to them, but unfortunately those emails don’t change my  view on this.

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 

No, on the other way around. The actual PDP is simple, very close to what we have in LACNIC and APNIC, just needs to polish some small detail. The complexity comes from your proposal. This proposal comes from the best PDP (in my opinion), the RIPE one.

However, there is a *mayor* difference, RIPE PDP is meant for *ONLY* for consensus in the *LIST*. Trying to use this for consensus in the meeting (and the list) doesn’t work the same way. In adds so much complexity that will not help the community to increase the participation, but on the other way around.

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 .

Responding to both questions in one. RFC7282 is very useful for this, nothing else is needed, but the most important aspect is that is up to the chairs, with no specific distinction among what you call “minor and major”. Otherwise, we will have defined this in RFC7282. In fact, a definition of rough consensus is “an extra” in a PDP, is just for people to read a “short” summary of RFC7282, and not need to go there. Good to have it there, but not to make it more complex with “sub-definitions” of objections that, again, is up to the chairs to define. Every proposal is a new “world”, and the chairs are selected by the community for that decision.

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. 

The problem is that you don’t have a specific timing for how much time a proposal needs to be discussed in the list if presented to close to the meeting, and then how much time should the discussion continue in the list. Frank already mention this problem as well.

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

Everyone is not consensus! There are occasions where 100 people may be against a policy proposal, and even do, reach consensus, because objections raised have been addressed/refuted, even if the 100 people continue to be against.

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 

You’re trying the define what is major and minor objection. This is against the chairs, selected by the community, self-decision.

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.

The wrong thing is about trying to use a PDP which is used only for decision in the list (such as IETF and RIPE PDP). I will agree if we are trying to make a process only for the list. In this case, just use the RIPE one (there is no copyright on policies, so they can be used from one region to another). Is not related to the community maturity at all, is related to try to use a process for a different thing that it was designed for.

The actual PDP is not broken, so once more, we just need to polish it, not to increase its complexity. We want to make as easy as possible for newcomers to participate.

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.

The best way for the community to reach consensus when several choices are possible, is to put in the table all those choices. This is very constructive if you put aside the personal attacks. The PDP is not about authors “competing”, is about getting the best possible outcome from all the discussions.

Sometimes, we can have TWO alternative different ways to do something. Sometimes, there is not a way in the middle. The only way for the community (in a consensus bases process) to take a decision, when only 5-10 people participate in the list, is to expose BOTH choices in competing proposals, and the community to take a decision (few people in the list, more people in the meeting).

If the process is *only list-based* as in the IETF or RIPE, then we are fine, we can just ask the people in the list “hi guys, we have two choices, we need to decide *now* which one we go for, otherwise we will need to decide in the meeting and then it means an extra delay of 6 months, until the next meeting”.

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 .

If in the list you have only 5-10 people contributing, 5-10 people can block a valid proposal, because they don’t like it and indicate “out-of-scope”. Again this is wrong.

9) End of discussion phase brings subjective documentation of the process, biasing the community.
Can you elaborate ? 

“At the end of the Discussion Phase, the PDWG Chairs provide a summary of the discussion highlighting the close and open issues” and next points. Again, because the list participation is not big, what the chairs may say in the list, may bias other participants. In my opinion chairs only need to provide a summary when declaring consensus.

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 

What I’m saying is that you may need more aspects depending on each policy proposal, so I suggest not citing what is needed, staff is already doing a good job on that. However, and this is my “but”, staff need to have freedom on that, and specially make sure to address their understanding of the proposal with authors *before* publishing it, otherwise it may bias the community understanding. AFRINIC is already doing that very well, according to my experience.

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 

What I’m saying is that with the current proposal, it is not clear the timing to achieve consensus in the list vs. the meeting. This is part of a previous comment already.

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. 

I don’t agree on this, should be part of the procedure, and in fact,  we needed to change the PDP in RIPE regarding something similar to this, as I discovered a flaw and as a consequence submitted a policy proposal for that. Same in LACNIC. Both reached consensus already and has been implemented.

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

I understand that, but the text is not clear about “who” request the waiver and to “whom”.

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 ? 

Same point as mention before. https://www.ripe.net/participate/policies/proposals/2018-04

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? 

This is against the full purpose of the PDP. A single community member can be for a proposal, and be right even being against the FULL community (because the law participation). Again this is against the consensus definition.

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/

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

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