Hi Adam,
By the way, thanks a lot for all the inputs, just sorry that we only get them from one person and they are so late. If we can get discussions more time ahead the meetings, we can get much better text, for sure! Below, in-line. El 17/2/20 11:55, "Adam Gosling" <em...@adamgosling.com> escribió: Hi Jordi My comments are inline New version: Step 2: Consensus Determination Consensus is defined as “rough consensus” (RFC7282) as observed by the Chairs. You are making a significant change, but presenting it as a “clarification”. -> Again, for me, in my native language, this is clarifying the situation. I don’t think it makes sense to discuss that, otherwise, we turn each proposal into a language discussion, which in turn, it will be differently understood by every non-native English speaker. The relevant thing here is what we actually do in the process and adapt the text to it, otherwise, we aren’t following our own PDP (our own rules). It is okay to consider adoption of IETF definitions of “rough consensus” to use in the APNIC Policy Process, but this is not a clarification. To be clear, the SIG doesn’t currently use the “rough consensus” model in RFC 7282. It uses the consensus model in the APNIC SIG Guidelines. https://www.apnic.net/community/participate/sigs/sig-guidelines/#steps -> The first problem we have here is that those guidelines were developed long time ago (2 decades or so), when we had many SIGs, and they were developed by the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t mention anything about the guidelines. This is not a mere editorial comment, it requires the community to accept those guidelines in a modification (thru a policy proposal) of the PDP. The third problem is that the PDP talks about “general agreement”, while the guidelines talks about “consensus”. It is a matter of English wording? I don’t know, but making it clear is good for everyone. Otherwise a newcomer will not see in the meeting that we are following our own process (because we aren’t!). -> If I recall correctly, when asked at least one of the co-chairs about what they recognize as consensus, and I believe is the way they explain at the beginning of each Policy SIG, they use the rough consensus definition and I’m almost sure they even mention the IETF RFC. The RFC is similar, but fundamentally different. Changing this in the PDP is not just a word tweak. It would result in a different approach from the Chairs and participants. There is no concept of “Minor” and “Major” objections in RFC 7282, for example. -> The RFC doesn’t provide the “operational” details, it is an informational document, so nothing precludes the co-chairs for their assessment to still make some “classification”, but again, the guidelines aren’t part of the PDP, unless we change it. I think they key here, and again, I believe is the understanding of the chairs, if I got it correctly, we aren’t counting hands or votes, but instead we declare consensus “when all the issues are addressed, but not necessarily accommodated”, which is the “short” description of the RFC. Consensus is determined first considering the SIG mailing list, other electronic means, and the SIG session, and afterwards at the Member Meeting. I’m supportive of the spirit of this change. It’s a bit late in the day to be proposing changes, but I would have written: “The Chair(s) assess if the SIG has reached consensus on a proposal by considering discussions both on the mailing list and at the Open Policy (Policy SIG) Meeting. The Chair(s) may use measurement techniques to take the temperature of the room. Consensus must be reached first at the SIG session and afterwards at the Member Meeting for the process to continue." -> I think is not late if we get some other inputs in the list … people supporting this one? I’m fine either way. For me the shorter version works fine, but again, there may be tiny English language details … What about (also reading your next paragraph and assuming that it is the Executive Council Chair, but this is easy to change in the final text if we send a new version and my recall or the actual situation is wrong): “The Chair(s) assess if a proposal has reached consensus by considering discussions both on the mailing list, other electronics means and at the SIG Meeting. Consensus must be afterwards sustained at the Member Meeting for the process to continue, as observed by the Executive Council Chair.” -> Note that my wording allows changing/evolving the (electronic) tools without requiring a PDP change (even incorporating several to facilitate the participation increase), and then there is no need to explicitly say that the tools are used for “measuring”, because that’s part of the consensus process. Also use SIG because this PDP seems to apply to policies developed by other SIGs, right? (if this is not currently the case). I think retaining the “process to continue” wording is important. I also think there is a lack of clarity about who is deciding Consensus at the Member Meeting. Is it the APNIC Executive Council Chair? The Chair of that particular meeting? The Policy SIG Chair? Or the Co-Chair presenting the report? If there is no consensus on a proposal, the authors can decide to withdraw it. This removes discretion from the Chair (and the SIG), to abandon a proposal if an Author repeatedly persists with the same unpopular idea. I think that’s interesting and worth discussing if that’s what we want. -> Which I think is wrong. It is inappropriate (in my opinion) that (and it may be again an English understanding) chairs can “abandon” on behalf of the authors (I will understand “force withdrawal”). If there is an unpopular idea, the community will not reach consensus. That’s it. Instead, chairs can decide NOT allocate time in the agenda (if other newer proposals require more time) for a proposal that is not getting consensus after several attempts, but I think it has been demonstrated many times, that ideas that doesn’t work on the first round, may work after 3-4 consecutive rounds (because the lack of inputs in the list take much much much longer), and even sometimes, authors may decide not to continue, and after some years come back and then in works. This is normal, because all this is evolving all the time. Otherwise, the proposal will be considered as expired by the next OPM, unless a new version is provided, restarting the discussions with the community. I like the idea that a proposal has to change before it can be re-presented. In the past, authors have just re-presented the same proposal until they get an friendly crowd and it passes. The effects of this have been negative IMO. Also, could I just add white space to the proposal and say that it has changed? How about this wording? "Otherwise, the proposal will be considered expired unless a new version incorporating SIG feedback is provided before the next “Proposal Deadline” to restart the discussions.” -> Again, let’s see if there are further inputs and then makes sense to send a new version tomorrow maximum? However, even if I like it, the timing is not correct, as the proposal deadline is for new proposals, not for new versions, so it needs some tuning. Maybe: “Otherwise, the proposal will be considered expired unless a new version incorporating feedback is provided before the next OPM relevant deadline, to restart the discussions” I hope these suggestions help. It is very difficult to make changes to the PDP. This would also require changes to the SIG Guidelines. -> I still thing the guidelines aren’t useful neither have been ever approved by the community, and instead either we make a Task Force to update the PDP and incorporate the guidelines, or to update the PDP to refer to the guidelines *and* the guidelines get also approved following the PDP. Regards, Adam Please, update the version number of this proposal with these changes, which I guess clears your impact assessment as well. Regards, Jordi @jordipalet El 14/2/20 14:47, "Srinivas Chendi" <sig-policy-boun...@lists.apnic.net en nombre de su...@apnic.net> escribió: Dear SIG members, Here is the Secretariat impact assessment for proposal “prop-134-v001: PDP Update” and the same is also published at: https://www.apnic.net/community/policy/proposals/prop-134/ Staff comments -------------- No foreseen change on APNIC Services procedures or systems as a result of this policy proposal. For reference and definition of “Rough Consensus” suggest adding RFC 7282 to the proposed text. It is difficult to keep track of proposals “expire in six months” may be change to “expire at the next OPM”. Technical comments ------------------ No comments. Legal comments -------------- Given that rough consensus is defined under RFC 7282 - no further comments. Implementation -------------- within 3 months. Regards Sunny On 20/01/2020 10:23 am, Bertrand Cherrier wrote: Dear SIG members The proposal "prop-134-v001: PDP Update" has been sent to the Policy SIG for review. (This is a new version of "prop-126" proposal abandoned after APNIC 48 as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.) It will be presented during the Open Policy Meeting at APNIC 49 in Melbourne, Australia on Thursday, 20 February 2020. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: * Do you support or oppose this proposal? * Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. * Do you see any disadvantages in this proposal? * Is there anything in the proposal that is not clear? * What changes could be made to this proposal to make it more effective? Information about this proposal is available at: http://www.apnic.net/policy/proposals/prop-134 Regards Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs ------------------------------------------------------------------------ prop-134-v001: PDP Update ------------------------------------------------------------------------ Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com> 1. Problem statement The actual PDP doesn’t support the usage of electronic means to “measure” the consensus. However, “Confer” is being used. This should be clarified, or otherwise the process is not fair (remote participants don’t know about it reading the PDP) and can be considered a violation of the PDP itself. The PDP also don’t have a formal process to withdraw a proposal, and doesn’t force the authors to keep editing it according the community inputs, or otherwise, allow the SIG chairs to declared it as expired. Finally, as editorial change, the expression “rough consensus” (RFC7282) is used instead of “general agreement”, so it is consistent with the actual practice. 2. Objective of policy change To resolve the issues above indicated. 3. Situation in other regions The PDP is different in the different RIRs. 4. Proposed policy solution Actual Text Step 2: Consensus at the OPM Consensus is defined as “general agreement” as observed by the Chair of the meeting. Consensus must be reached first at the SIG session and afterwards at the Member Meeting for the process to continue. If there is no consensus on a proposal at either of these forums, the SIG (either on the mailing list or at a future OPM) will discuss whether to amend the proposal or to withdraw it. Proposed Text Step 2: Consensus Determination Consensus is defined as “rough consensus” as observed by the Chairs. Consensus is determined first considering the SIG mailing list, other electronic means, and the SIG session, and afterwards at the Member Meeting. If there is no consensus on a proposal, the authors can decide to withdraw it. Otherwise, the proposal will expire in six months, unless a new version is provided, restarting the discussions with the community. 5. Advantages / Disadvantages Advantages: Fulfilling the objectives above indicated and making sure that there is no formal discrimination with community members that aren’t able to travel so they know that they can participate via the Confer or other systems developed by the secretariat. Disadvantages: None foreseen. 6. Impact on resource holders None. 7. References http://www.lacnic.net/679/2/lacnic/policy-development-process https://www.ripe.net/publications/docs/ripe-710 Cordialement, ------------------------------------------------------------------------ Bertrand Cherrier Micro Logic Systems https://www.mls.nc Tél : +687 24 99 24 VoIP : 65 24 99 24 SAV : +687 36 67 76 (58F/min) * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy ********************************************** 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. * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy ********************************************** 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.
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
