This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ripe-list] RIPE Working Group Chair Collective Meeting Summary
- Previous message (by thread): [ripe-list] RIPE Working Group Chair Collective Meeting Summary
- Next message (by thread): [ripe-list] New on RIPE Labs: #LetsGreenTheWeb with ClimateAction.tech
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Tue Feb 9 12:44:33 CET 2021
A more in depth reading of "Review of the RIPE Appeals Procedure", which I already sent to the chairs-team: While I basically agree with most of the points, I've some comments: Regarding recommendation 1, may be some of the timings and roles should be better defined in the PDP. I think the PDP must be self-contained, not PDP in one document and other documents, it becomes a mess, difficult to follow and at the end everything needs to be decided by the community bottom-up consensus process. Regarding r. 2, this was one of the points that I raised. I'm not reviewing now all the emails exchange, just from top of my head, I'd doubts during the process. I think it must be clear that, as part of the process (with the actual PDP, not considering yet my policy proposal) an ad-hoc mailing list with the non-recused WGCC should be created when there is an appeal to handle all the process (I guess including the Policy Officer or other RIPE NCC staff). The list of those participants should be crystal clear and published, right after the appeal is submitted, as a matter or transparency. .... I was writing this at the same time as reading the document ... I just realized that this is your r. 3! R. 4. I understand that the recusing also must be done for those WG chairs that *have* participated in the policy proposal discussion. I recall (as an example), in this concrete appeal, some of them actually self-recused, others not. One recused because he was already working with me in another policy proposal for the same topic. I think this is fair, but somehow it should be automatic. I still believe that this requires a PDP update. R. 5. The appeal said things that are against the PDP ... or against what chairs declared in the non-consensus decision. I've sent an email about that. Again, from top of my head: there is nothing in the PDP that avoids me to send a new version of the policy proposal (there is NO WAY in the PDP for any WG chairs to REJECT or DELAY the publication of a proposal/version, etc.), however chairs said that. And the appeal result indicated otherwise ... R. 6. I think my policy proposal resolves that. May be just need to detail that "one of Appeal Committee members will be selected by the group to chair the sessions". R. 7, looks a duplication of previous inputs, anyway, I think again my proposal already resolves that, as it is clear that the appellant also must have the right to indicate who has a conflict with him/her and should participate in the appeal. R. 8. Agree. R.9. I don't agree here. The PDP is clearly modified by the PDP itself. This is also the way followed by all the other RIRs, and the way we used to make the last change (I was the author of https://www.ripe.net/participate/policies/proposals/2018-04). However, I agree that it will be better to remove "The RIPE Chair is the author and owner of this document.". There is actually something that I've already discussed several times with Marco (when he was PO) and Hans Peter (when he was RIPE Chair) and we never progressed about that: - In none of the other RIRs the policies have "attribution" neither "acknowledgments". A Policy proposal becomes a policy because the community "edits" it by means of work with the author(s). If we decide that the policies should list the authors and ack section, let's do it for *ALL THEM*, like the IETF documents. When I edit an IETF document, I remain for the entire life of the document (RFC, STD, etc.), as author(s), and I list in the ack section *all* the people that has participated (not those that just provided grammar edits ...). In the RIPE policies, some of them have an attribution or ack section (I never used that in any of my policy proposals), but others did (examples RIPE-710, RIPE-705, RIPE-682, etc.). I think we should be consistent. Or we include that section in all the "actual" policies, or we delete it from all them (I prefer this one, it is a community work). R. 10. Radically disagree here! This kind of filtering is artificial, and only leads to "luck". If those that don't like a proposal idea are more pro-active, the proposal is dead and has no opportunities. No other RIRs are doing this. ARIN is a bit different because the AC. This is in fact against the PDP, in the sense, that as said before, chairs can't delay, or reject a policy proposal if the scope is the one in the WG. Regarding having co-authors, I usually try, like in IETF, but in most of the occasions the experience shows that is negative. I've been in situations in IETF and LACNIC, where my co-authors, didn't replied at all, I was "holding" a new version of the proposal because lack of response, etc., etc., etc. I must say that, this even happened to me in one of the RIPE policy proposals (not in all the others that I've got co-authors). So, yes, I'm happy to work with co-authors, but only if they are really proactive and that means reacting in hours, not "weeks" or "months". Note that my inputs are not only as the one that formulated the recent appeal, but also trying to be *outside of that situation*. In fact, that was the reason why I sent the policy proposal, which I still think it is absolutely necessary. I don't understand why hast not been published yet. The PDP doesn't allow delaying or "holding" a proposal. I agree that editorial inputs, clarifications, etc. can be provided, etc., but nothing else! If you think that some of the comments here should be incorporated in the policy proposal, I've no problem with that, but I'm clear that it must be a different body, not the WGCC and that we must move on now! I'm clearly unsatisfied with the appeal result, however, I was completely sure that will be the result when I submitted it and understood the procedure re-reading RIPE-710 and knowing that many co-chairs have participated in the policy proposal discussion. Same group of people (colleagues) from the relevant WG chairs, can't "most of the time" objectively, reject the decision of their colleagues. It is just human! Regards, Jordi @jordipalet El 9/2/21 11:58, "ripe-list en nombre de Mirjam Kuehne" <ripe-list-bounces at ripe.net en nombre de mir at zu-hause.nl> escribió: Dear colleagues, The RIPE Working Group Chairs met in January to review the appeal and to exchange experiences with regard to the RIPE Policy Development Process. We also discussed the meeting plan for the upcoming RIPE 82 Meeting. You can find a summary from the meeting here: https://www.ripe.net/participate/ripe/wg/wg-chairs/working-group-chair-collective/summaries/working-group-chair-interim-meeting-summary Kind regards, Mirjam Kühne RIPE Chair ********************************************** 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.
- Previous message (by thread): [ripe-list] RIPE Working Group Chair Collective Meeting Summary
- Next message (by thread): [ripe-list] New on RIPE Labs: #LetsGreenTheWeb with ClimateAction.tech
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]