- anti-abuse-wg - mailman.ripe.net

Re: [anti-abuse-wg] Appeal against the Anti-Abuse WG Co-chairs decisions on proposal 2019-04 (Validation of “abuse-mailbox”)
by JORDI PALET MARTINEZ 12 Nov '20

12 Nov '20

Hi Mirjam, See my responses below, in-line as many clarifications are clearly required, not just because this appeal, but because there is a misjudgment of the PDP itself. Regards, Jordi @jordipalet El 26/10/20 9:07, "Mirjam Kuehne" <mir(a)zu-hause.nl> escribió: Dear Jordi, Regarding the appeal you submitted on 5 October to the RIPE Anti-Abuse Working Group mailing list, I would like to inform you about the decision of the RIPE Working Group Chairs Collective (according to the procedure as defined in ripe-710). [Jordi] I don't think the PDP has been followed in full for this appeal. For example, there was not announcement of the publication of the appeal in the web site. The WG Chairs Collective (WGCC) decided to uphold the decision of the Co-Chairs of the Anti-Abuse Working Group. Please find below their detailed response. Kind regards, Mirjam Kühne RIPE Chair ======== Summary ======= The WGCC does not find sufficient reason to overturn the ruling of the Anti-Abuse WG chairs on proposal 2019-04 (Validation of "abuse-mailbox"). If Jordi wishes to bring a new proposal that he thinks may achieve consensus, we note that 2019-04 was being considered during an unusual time, when we have not had face-to-face meetings due to the COVID-19 pandemic. So it faced difficulties not normally facing a policy proposal. As always, the Anti-Abuse WG chairs may decide not to adopt any new proposal. [Jordi] Could you clarify this paragraph; I can't parse it. Scope ===== The WGCC considers the appeal process to be solely to determine if the working group chairs made a reasonable declaration of consensus or lack of consensus. The appeal process is able review whether the process was followed, or whether there was bias shown in the declaration. The appeal process will not re-visit any of the points for or against the proposal. [Jordi] Following the PDP, I can't agree with this. Can you clarify? Discussion ========== The appeal submitted includes several points that the WGCC found important to consider. These are discussed here. Points outside of the scope of the appeal process are omitted. RIPE NCC Impact Analysis ------------------------ The appeal will not review the accuracy of the RIPE NCC impact analysis. The WGCC defers to the expertise of the RIPE NCC staff who performed the analysis and the members of the Anti-Abuse WG who received the analysis. Further, an impact analysis is information intended to be helpful to decide whether to adopt a policy. The RIPE community is free to assign whatever weight it wishes. [Jordi] However, according to this, the co-chairs should also consider that the justification provided by the author against the objections is clearly demonstrating that the analysis impact is wrong in certain aspects, so those objections can't be accepted as valid. Discussion During the Review Phase ---------------------------------- The need to re-state opinions was explicitly mentioned in the e-mail moving the policy proposal to the review phase. It is unfortunate that the importance of this was not clear to Jordi. Possibly in the future this can be highlighted in some way. [Jordi] This is against the PDP. The chairs can even say I must sing a song, but the only valid process is the one CLEARLY STATED in the PDP. Nothing else. Otherwise there is a clear subjectivity in the process which invalidates it. Timing of Consensus Declaration ------------------------------- Jordi mentions several possible changes to the policy proposal which may have led to consensus. He suggests that the declaration of consensus was made too soon. We recognize that this is a bit of an odd time, due to COVID-19. This has removed one of our valuable tools, the face-to-face meetings. The already-tricky job of the working group chairs in the PDP has been made harder. We rely on the chairs of the WG involved to decide whether or not a proposal is likely to ever reach consensus. There are no guidelines given for this decision. We find that the Anti-Abuse WG chairs were reasonable in the timing of declaring that there is no consensus. Specific Points in Conclusion ----------------------------- The conclusion states: 1. It is not acceptable to declare lack of consensus and at the same time recognize that there was “some clear support for the policy during the Discussion Phase”. This is not true. Having support for a policy does not _necessarily_ mean there is consensus. [Jordi] Exactly the same that declaring no-consensus based on justifications that have been refuted by the author, is not acceptable. 2. It is not acceptable to, due to the lack of messages in the Review Phase, instead of extending it, considering the summer vacations period, declare lack of consensus. We find the judgment of the Anti-Abuse WG chairs to be reasonable in not extending the Review Phase. [Jordi] Based on what? Because this is even clearly against the text of the co-chairs decision. You also are recognizing across the text that the circumstances during the Covid are special, so how come then it should be acceptable not to extend the review phase considering the lack of responses, and the summer period in addition to the Covid itself? 3. It is not acceptable to accept repeated objections as valid when have been already refuted in a previous phase. The consensus declaration should defer to the community and what they consider valid. It appears to have done so in this case. [Jordi] Once more, lack of consensus can't be determined based on objections which are invalid as they have been reasonably refuted by the author and even other community members. 4. It is not acceptable to, considering the PDP (“The PDP is designed so that compromises can be made and genuine consensus achieved”), subjectively decide that “regardless of possible edits, reaching consensus in the short or medium term”, when there are possible ways to address the objections, which have anyway already being addressed. We find the judgment of the Anti-Abuse WG chairs to be reasonable in declaring a lack of consensus. [Jordi] This is unacceptable. If the discussion shows that changes to the proposal can bring a new version which may achieve consensus, then it should be allowed. We know that different proposals have taken different time and different number of versions to achieve consensus, so such decision about if a proposal can reach or not consensus, can't be based on a subjective decision. New Policy Proposal ------------------- In principle there is nothing to prevent Jordi or anyone else from submitting an updated version of 2019-04. However, in the Address Policy working group having submitted an unsuccessful policy proposal did prejudice the working group against accepting other submissions. So there is some possible concern that an updated version would have a more difficult time. There are many factors to balance when deciding what proposals to accept, and the work of balancing them is up to the working group chairs. So we do _not_ explicitly request that the Anti-Abuse working group chairs adopt any subsequent policy proposals. We _do_ ask that they give extra consideration to the unusual circumstances that we are attempting to make policies in. We do not have any recommendation to Jordi whether he or anyone else should submit an updated version of 2019-04. [Jordi] I can't parse this. It looks contradictory. Previous text seems that is ok to the co-chairs to reject a new version, but here it is clearly stated that anyone can do it? Are we talking about a new version of the same proposal or a new proposal? Working Group Chairs Excluded ============================== The working group chairs of the Anti-Abuse working group were not part of the discussions regarding the appeal. A number of other working group chairs recused themselves from the appeal. These were: * Erik Bais * Gert Doering * Denis Walker In addition, Mirjam Kühne and Niall O'Reilly recused themselves from discussion and writing of the appeal. Recommendation to All RIPE WG Chairs ==================================== We recommend that all RIPE WG Chairs provide extra help for all policy proposals while we are struggling to deal with lack of face-to-face contact. The form of this help will vary depending on the proposal. The rest of the WGCC is available to discuss any topics related to this if any WG chairs want additional feedback or ideas. This advice does not strictly fall within the scope of the appeal, but the appeal brought the issue to the attention of the WGCC. We consider it important to mention here. ********************************************** 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.

6 9

Post in RIPELABS blog on Internet standards deployment
by Wout de Natris 27 Oct '20

27 Oct '20

Dear colleagues, Following my request to you last summer, to participate in a questionnaire on the deployment of Internet standards and ICT best practices, I have written a post on the outcomes and the next steps to be taken in the DC-ISSS. You find the link to the post attached. The DC-ISSS is looking for experts interested to work with us on either of the three topics that have been given priority unanimously by those currently participating already: Procurement and business case; Education curricula; Security by design IoT. Please let me know should you have any questions or would like to know more. Those interested can join the DC-ISSS through the website of the Internet Governance Forum (IGF). Kind regards, Wout de Natris https://labs.ripe.net/Members/wout_de_natris/invitation-to-igf-dynamic-coal…

2 2

Appeal against the Anti-Abuse WG Co-chairs decisions on proposal 2019-04 (Validation of “abuse-mailbox”)
by JORDI PALET MARTINEZ 26 Oct '20

26 Oct '20

Hi all, This appeal (attached in PDF) follows the process outlined by ripe-710 (RIPE PDP). Regards, Jordi @jordipalet ********************************************** 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.

7 8

Draft Agenda - Anti-Abuse WG @ RIPE 81
by Brian Nisbet 19 Oct '20

19 Oct '20

Colleagues, Here is the draft agenda for our session next week. It will take place via the RIPE 81 meeting platform at 10:00 CET/UTC +1 on Thursday 29th October. As mentioned, there is likely some time still available if anyone has anything they'd like to bring to the WG. Please note C.2. where the Co-Chairs would like to facilitate some open discussion on where the WG feels we might go in regards to abuse validation and other similar topics. A. Administrative Matters * Welcome * Scribe, Chat, Stenography * Chat Etiquette * Ratings Where Appropriate * Approve Minutes from RIPE 80 * Finalise agenda B. Update * B1. Recent List Discussion C. Policies - *C.1. Status of Policy Proposal 2019-04 - Validation of "abuse-mailbox" *C.2. Open discussion on abuse validation & next steps D. Interactions - E. Presentation - X. A.O.B. Z. Agenda for RIPE 82 Brian Co-Chair, RIPE AA-WG Brian Nisbet Service Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

Final-ish Call for Agenda Items: AA-WG @ RIPE81
by Brian Nisbet 14 Oct '20

14 Oct '20

Colleagues, The AA-WG will be meeting at RIPE81 on Thursday 29th October at 10:00 CET. We will be posting a draft agenda later this week, but we still have some time free, so if you would like to raise any items with the WG, please contact the Co-Chairs at aa-wg-chair(a)ripe.net Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Service Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

[db-wg] Fw: NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Hi Lutz Good try but this script does not do it. Firstly, if you start with the allocation object it needs to be -rM in the first query. Then you are only looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:" attribute in the object. It may have both in which case the local attribute overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage this feature it is not just about producing a list of abuse email addresses. It is knowing where these are referenced within a hierarchy and knowing which parts of the hierarchy are covered by which addresses. I agree that most resources will only have a single abuse contact referenced from their single ORGANISATION object. However, we were pushed hard by the community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume therefore that this feature has been used. So we already have a mix of abuse contacts referenced from both ORGANISATION and resource objects. When this was asked for the emphasis was on 'ease of use' to add these contacts. Probably no one gave much thought to how these contacts will be cleaned up when no longer relevant. It's most likely that someone will ask someone to remove it. Knowing human nature it is more likely some will just be forgotten about. If the contact is still there it is still active, but maybe no one is reading that email address any longer. I am not an operator so I don't know how many end user customers in large networks handle their own abuse reports. Or how many sub allocations handle abuse with their own customers handling abuse. So I don't know how complex this will get and maybe all operators already have good procedures in place to manage all this. That is why I am asking the question...is such a visualisation tool needed, useful or a waste of time? As an analyst, I can only see how complex this 'could' become over time. Unless we go back to the drawing board and redesign the abuse contact system (again) this is not going to be simplified any time soon. cheersdenis co-chair DB-WG On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg <db-wg(a)ripe.net> wrote: > > We need to take some action on these old NWIs. Either we move forward > with them or we cancel them. It is difficult to draw a consensus on 2 > comments. Can you please give us a couple of minutes of your time and > let us know if this NWI-1 is needed, useful or a waste of time. > > I share the view already expressed. If we need a tool, maybe the problem > is somewhere else. I support any proposal, that comes to the same result as the ripe whois database tool. It's not really hard to do correctly. #! /bin/sh getripe="whois -h whois.ripe.net --" $getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do $getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do $getripe -r $av | fgrep abuse-mailbox done done | tail -1 In order to fix the issue on the database side, it's necessary to prevent any occurrence of "abuse-mailbox" in all objects beside an newly created "abuse-contact" type, which is only allowed to referenced in the "abuse-c". See here for a corner case: https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C

2 1

NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss.... cheersdenis co-chair DB-WG

4 6

Re: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
by Stephane.Dodeller＠swisscom.com 23 Sep '20

23 Sep '20

Hello Leo, Hello all, > I have no objection to creating useful tools for people to use when > managing their resources. That said, whenever the data structure is so > complex that a special tool is needed to help people understand it, I > wonder if the real problem is the data structure. +1 Such a tool would certainly bring something, but may not be needed if we could simplify the structure in the first place. Best regards Stéphane Dodeller

2 1

Invitation to IGF survey and workshop on Internet standards deployment
by Wout de Natris 21 Sep '20

21 Sep '20

Dear colleagues, Last year you were invited to a survey concerning the slow deployment of Internet standards. This led to a report published in March of this year. Below you find the next step towards deployment, to work on recommendations and actions. The deployment of Internet security-related standards and ICT best practices is a topic that continues to be the subject of important discussion worldwide with the aim of achieving a more secure and safer online environment that is necessary to support the rapid adoption of new digital technologies. This has been made even more urgent by the COVID-19 pandemic. I am sure you would agree that it is time to move on from what has been largely an uncoordinated and technical debate spread across various fora, and initiate global stakeholder cooperation that will have a positive impact on economic and social well-being through helping digital technologies to transform everybody’s daily lives. As you may know, the UN Internet Governance Forum is establishing a new Dynamic Coalition on Internet Standards, Security and Safety (DC-ISSS) with the aim of achieving this objective and I am now writing as the leader of this initiative to invite you as a leading expert to join this important multi-stakeholder coalition. The intended outcomes of the DC-ISSS will be recommendations for actions by key policymakers and decision-takers that will enable security-related Internet standards and best practices to be deployed more rapidly and with greater determination and commitment. By involving stakeholders like yourself we believe that we can at last make a difference in making deployment more effective and widespread. It has to stop to be a, primarily, technical debate, to be changed into a digital healthcare topic. As a first step, the coalition needs to prioritise its work and finalise its work plan. A preparatory session for this purpose will be held during the upcoming IGF 2020 on Wednesday 4 November at 09.40 – 11.10 CET. A short questionnaire has been drawn up to help with this process. It would be appreciated very much if in addition to considering the invitation to join the coalition, you could complete this questionnaire which can be accessed at: https://survey.sogosurvey.com/Survey1.aspx?k=SsQYPPXWsRsPsPsP&lang=0. Our deadline for responses in 7 October. It does not take up more of your time than five minutes at a maximum. The formal launch of the DC-ISSS will be held in a separate session on Friday 6 November from 10.10 - 11.40 CET when the establishment of thematic working groups will be announced and the work programme presented. This will be followed by an online discussion with stakeholders. You are cordially invited to this as well of course. Further information about the DC-ISSS can be found on the IGF website at: <https://www.intgovforum.org/multilingual/content/dynamic-coalition-on-inter…> https://www.intgovforum.org/multilingual/content/dynamic-coalition-on-inter… Here is the link to join the DC-ISSS email list in order to receive updates and be informed of progress: https://www.intgovforum.org/multilingual/content/dc-jobs-mailing-list Please also bear in mind that in order to participate in the work of the DC-ISSS you need to register for IGF 2020. This can be done by accessing the registration page at: https://www.intgovforum.org/multilingual/content/igf-2020-registration If you have any questions about the aims of the DC-ISSS, its objectives and the process for planning its work, please do not hesitate to get in touch - and of course I and the support team comprising Mark Carvell and Marten Porte would welcome any thoughts and suggestions you may have for making this important Dynamic Coalition a success in achieving its objectives in creating greater security and safety online for all users worldwide. Best regards, Wout de Natris - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - De Natris Consult Kamerlingh Onnesstraat 43 Tel: +31 648388813 2014 EK Haarlem Skype: wout.de.natris denatrisconsult(a)hotmail.nl<mailto:denatrisconsult@hotmail.nl> http://www.denatrisconsult.nl Blog http://woutdenatris.wordpress.com

1 0

2019-04 Policy Proposal Withdrawn (Validation of "abuse-mailbox")
by Petrit Hasani 09 Sep '20

09 Sep '20

Dear colleagues, The policy proposal 2019-04, "Validation of "abuse-mailbox”” has been withdrawn. The proposal aimed to have the RIPE NCC validate "abuse-c:” information more often and introduce a new validation process. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposal did not reach consensus and the WG chairs did not feel that any further redrafting of the proposal would achieve consensus. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC

5 5