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!
El 17/2/20 11:55, "Adam Gosling" <firstname.lastname@example.org> escribió:
My comments are inline
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.
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?
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.
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.
IPv4 is over
Are you ready for the new Internet ?
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.