<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Cuerpo en alfa";
panose-1:2 2 6 3 5 4 5 2 3 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Ubuntu;
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML con formato previo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLconformatoprevioCar
{mso-style-name:"HTML con formato previo Car";
mso-style-priority:99;
mso-style-link:"HTML con formato previo";
font-family:Consolas;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
margin-bottom:7.1pt;
margin-left:0cm;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EstiloCorreo20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=ES link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=ES-TRAD style='font-size:12.0pt;mso-fareast-language:EN-US'>Hi Komi, all,<o:p></o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div><p class=MsoNormal style='margin-left:35.4pt'>El 20/5/19 9:29, "Komi Elitcha" <<a href="mailto:kmw.elitcha@gmail.com">kmw.elitcha@gmail.com</a>> escribió:<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US style='font-family:"Ubuntu",serif'>Good morning from Africa, Jordi </span><span lang=EN-US><o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>Please read comments inline.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US>On 17/05/2019 18:06, JORDI PALET MARTINEZ via RPD wrote:<o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US>Hi all,<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>I've sent my raw notes about this policy proposal on 29th November 2018.<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>It is bizarre that you missed co-authors mail sent on February 18, 2019 [1] <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:12.0pt'>Just responded to them, but unfortunately those emails don’t change my view on this.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><span lang=EN-US style='font-size:12.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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 <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>However, there is a *<b>mayor</b>* difference, RIPE PDP is meant for *<b>ONLY</b>* for consensus in the *<b>LIST</b>*. 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.<o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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. <o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>Here is what I believe is still not resolved:<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>Can you clarify this point ? <o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>Can you define complexity in this context ? Can you also define what you mean by “critical technical objections” in your definition of Consensus ? <o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>See </span><a href="https://afrinic.net/fr/library/policies/2535-simple-update-of-the-pdp"><span lang=EN-US>https://afrinic.net/fr/library/policies/2535-simple-update-of-the-pdp</span></a> <span lang=EN-US><o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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 .<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:12.0pt'>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.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><span lang=EN-US style='font-size:12.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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. <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>4) Contradictory, consensus is not unanimity, even if not everyone consents to the decision of the group, consensus may be declared.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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.” <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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 <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>You’re trying the define what is major and minor objection. This is against the chairs, selected by the community, self-decision.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>6) Phases stated are complex and unnecessary. Looks like trying to copy the RIPE PDP but with broken things. Will difficult the community participation.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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.” <o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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).<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>If the process is *<b>only list-based</b>* 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 *<b>now</b>* 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”.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>8) The WG should not decide against a policy proposal if is in scope of the PDP (so adoption phase doesn’t apply).<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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 .<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>9) End of discussion phase brings subjective documentation of the process, biasing the community.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>Can you elaborate ? <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>“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.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US>10) Impact analysis should include “more”, but just objective inputs, and not bias the community.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>more than the followings ? <o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>• AFRINIC Ltd’s understanding of the proposed policy <o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>• Impact on the registry and Internet Number Resources <o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>• Impact on AFRINIC Ltd’s operations/services <o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>• Legal impact We trust staff to be objective in their analysis and community has the right to question and discuss the staff analysis <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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 *<b>before</b>* publishing it, otherwise it may bias the community understanding. AFRINIC is already doing that very well, according to my experience.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>11) What happens if the timing with the review phase and the next meeting doesn’t match?<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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 <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>12) In the Concluding phase, it is not clear why a proposal should go back to either the discussion or the review phase.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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. <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US>13) Implementation waiver from who? The implementation timing is up to the staff and should be informed in the impact analysis.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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.” <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>I understand that, but the text is not clear about “who” request the waiver and to “whom”.<o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US>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 …<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>can you elaborate on the change ? <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Same point as mention before. </span><a href="https://www.ripe.net/participate/policies/proposals/2018-04">https://www.ripe.net/participate/policies/proposals/2018-04</a><o:p></o:p></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US><o:p> </o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>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.<o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>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? <o:p></o:p></span></p><p style='margin-bottom:0cm;margin-bottom:.0001pt'><span lang=EN-US>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.<o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US>Regards,<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>Jordi<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US> <o:p></o:p></span></pre></blockquote><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>Hope it helps. <o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US>[1] </span><a href="https://lists.afrinic.net/pipermail/rpd/2019/008981.html"><span lang=EN-US>https://lists.afrinic.net/pipermail/rpd/2019/008981.html</span></a> <span lang=EN-US><o:p></o:p></span></p><p style='mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:0cm;margin-left:35.4pt;margin-bottom:.0001pt'><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:35.4pt'><span lang=EN-US>Komi Elitcha on behalf of co-authors <o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre style='margin-left:35.4pt'><span lang=EN-US>_______________________________________________<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>RPD mailing list<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><a href="mailto:RPD@afrinic.net"><span lang=EN-US>RPD@afrinic.net</span></a><span lang=EN-US><o:p></o:p></span></pre><pre style='margin-left:35.4pt'><a href="https://lists.afrinic.net/mailman/listinfo/rpd"><span lang=EN-US>https://lists.afrinic.net/mailman/listinfo/rpd</span></a><span lang=EN-US><o:p></o:p></span></pre></blockquote><pre style='margin-left:35.4pt'><span lang=EN-US>-- <o:p></o:p></span></pre><pre style='margin-left:35.4pt'><span lang=EN-US>KE<o:p></o:p></span></pre><pre style='margin-left:35.4pt'><a href="https://www.linkedin.com/in/komi-elitcha/"><span lang=EN-US>https://www.linkedin.com/in/komi-elitcha/</span></a><span lang=EN-US><o:p></o:p></span></pre></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
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.<br>
<br>
</body></html>